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ABSTRACT 



This thesis is an assessment of the current efforts in the development of a Marine 
Coips Tactical Command and Control System (MTACCS). The Marine Corps has been 
developing MTACCS for more than twenty years. The recent cancellation of a key 
component subsystem and the DOD reorganization efforts of the late 1980's caused a two 
year period of dormancy in this program. The driving goal of this assessment is to 
develop an understanding of the strengths and possible risks inherent in the new 
"revitalized" program that is now in renewed development. The assessment effort 
examines the history of the program, the feasibility of the new concept, cost effectiveness, 
systems engineering, and interoperability. Conclusions stress the importance of doctrinal 
consensus, adequate requirements definition, engineering the system as a whole, and 
evolutionary acquisition of modem command and control systems. 
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I. INTRODUCTION 



A. PURPOSE OF THE THESIS 

This thesis is an assessment of the current efforts in the development of a Marine 
Corps Tactical Command and Control System (MTACCS). The United States Marine 
Corps has been developing MTACCS for more than twenty years. Several significant 
events in the mid 1980’s resulted in a major upheaval within the Department of Defense 
and a subsequent reevaluation of the MTACCS concept. The Goldwater-Nichols Defense 
Reorganization Act of 1986 and the termination of a key MTACCS subsystem in 1987 
stand out as the most vital of these events. While development on other MTACCS 
subsystems continued, only nominal integration of these systems was achieved between 
1988 and 1990. The concept has only recently been "revitalized" after two years of 
dormancy. [Ref. 1] The assessment of this newest version of MTACCS will be 
concerned with five important areas: 

1. The impact of the termination of a key MTACCS subsystem for command and 
control of fire and air support. 

2. The feasibility of the new MTACCS concept. 

3. The cost-effectiveness of MTACCS. 

4. Marine Corps combat development practices. 

5. MTACCS level of interoperability. 
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The driving goal of this assessment is to develop an understanding of the strengths 
and possible risks inherent in the new MTACCS concept. Additionally, recommendations 
are proposed that offer methods of mitigating the impact of identified risk factors. 

B. OUTLINE OF THE CHAPTERS 

1. Chapter II. The Termination of MIFASS 

The Marine Integrated Fire and Air Support System (MIFASS) was a recent 
Marine Corps attempt at developing a key MTACCS component subsystem for fire 
support. The MIFASS program was canceled in 1987 after almost twenty years in 
development. One result of the termination of MIFASS is the use of new approaches to 
the development and acquisition of Command and Control systems. MTACCS is based 
on these new ideas. Chapter II details the difficulties encountered during the MIFASS 
program that ultimately led to the termination of the project. 

2. Chapter III. MTACCS Today: The Response to MIFASS 

The "revitalized" concept is a response to many factors. Important among 
these factors is the termination of the MIFASS program. Chapter III describes the 
MTACCS concept as it is currently envisioned. MTACCS, however, is only now being 
defined. Many of the guiding directives and strategy documents are still in draft. While 
the basic thrust of the new concept is stable, some changes in concept definition are 
occurring even as this thesis is being written. 
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3. Chapter IV. Feasibility Assessment 

The implementation of MTACCS is an extreme challenge. At least several of 
the objectives of MTACCS fall into the "high risk" category and may be difficult to 
achieve at any reasonable cost and expenditure of effort. The first assessment, then, is 
an evaluation of the feasibility of the MTACCS goals. While much of this evaluation is 
necessarily subjective, the question of feasibility must be addressed regardless of the lack 
of quantitative evidence. 

4. Chapter V. A Cost-Effectiveness Assessment 

It is often tacitly accepted that automation of a particular task has inherent 
benefits that always result in improved combat effectiveness. Is this the case with 
MTACCS? To what degree wUl automation of the command and control tasks bring 
about an improvement in combat effectiveness? The combat effectiveness assessment in 
Chapter V will address these questions. In addition, the cost of MTACCS must be related 
to its ability to increase effecdveness. Some investigation must be made to determine if 
spending funds on MTACCS is an optimal use of resources. 

5. Chapter VI. Combat Development Assessment 

Combat Development is a process used to determine the course of the Marine 
Corps in the years ahead. Combat Development affects doctrine, training, force structure, 
and equipment. The MTACCS system is a result of Combat Development practices. 
Chapter VI provides an overview of Combat Development and assesses its likely impact 
on MTACCS. 
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6. Chapter VII. MTACCS Interoperability Assessment 

The fifth critical area concerns interoperability. In October of 1988, the Naval 
Research Advisory Committee (NRAC) released a report on the intra/interoperability of 
Marine Corps command and control systems. The report cited several interoperability 
concerns with MTACCS at that time and proposed several recommendations to improve 
the interoperability posture of the Marine Corps. An obvious question then is "have the 
recommendations been given consideration"? Chapter VII will provide an assessment of 
the interoperability efforts of MTACCS and the levels of interoperability expected to be 
achieved. 

C. BACKGROUND AND fflSTORY OF MTACCS 
1. Background 

a. The Need for an Automated Command and Control System 

The National Security Act of 1947 requires that the Marine Corps provide 
rapidly deployable amphibious forces for contingency missions in support of the national 
strategy. A key statutory mission of the Marine Corps is to provide Marine Air Ground 
Task Forces (MAGTF) of combined arms, together with supporting air components, for 
service with the fleet in the seizure or defense of advanced naval bases and for the 
conduct of such land operations as may be essential to the prosecution of a naval 
campaign. The coordination of such a large number of forces and equipment deployed 
over a wide geographic area demonstrates the requirement for an automated command and 
control system to effectively manage the assets available. [Ref. 2:p 3-1] 
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In order to accomplish assigned missions. Marines are deployed in various 
states of readiness around the globe. In some cases. Marines and their equipment are 
prepositioned in strategic locations, in the vicinity of trouble areas. When Marines must 
be deployed, they must go through various phases and locations in order to ship their 
resources to the area of conflict. This requires an extensive amount of logistical and 
administrative processing, and validates the requirement for automation. [Ref. 2;p 3-1] 

Marines train on a daily basis for the conduct of war. This training and 
the keeping of personnel records requires a large amount of time and effort spent, not on 
training, but on processing. An automated system of personnel and training record 
keeping could significantly raise the amount of time spent on training and increase record 
accuracy. [Ref. 2:p 3-2] 

An automated command and control system that would be used in peace 
as well as combat would facilitate the prosecution of battle and make more effective use 
of the available resources. [Ref. 2:p 3-2] 

b. The Purpose of MTACCS 

The MTACCS concept is the implementation of separate, automation 
assisted Marine Air Ground Task Force (MAGTF) command and control systems which 
support tactical operations. MTACCS is to enhance the commander’s decision making 
capability and provide the tools necessary for effective and efficient command and 
control. MTACCS is to support maneuver warfare, focus on the operational level of war, 
support MAGTF internal functional requirements, and focus on the MAGTF area of 
influence. [Ref. l;pp 1,4] 
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c. Concept and Characteristics 

The objective of the MTACCS concept is to provide MAGTF 
commanders with an integrated set of systems which can receive, process, display, store, 
and distribute essential information. Figure 1 portrays the MTACCS concept as it is 
currently envisioned. The subsystems shown will be defined and explained in detail in 




6 



Chapter III. MTACCS is an engineering effort to manage the integration of developed 
and developing automated systems to support tactical operations. MTACCS will provide 
commanders with a semi -automated, secure, versatile, rugged, and integrated .system of 
tools to assist them in effective command and control. It consists of functionally oriented 
systems using a common design philosophy, equipment, operational procedures, data 
bases, and where appropriate, integration with other systems external and internal to the 
Marine Corps. MTACCS is based upon reliable digital communications to enhance 
planning, direction, coordination, and control of Marine forces. MTACCS will eventually 
provide the commander with one system to support both tactical and non-tactical 
functions while providing fused and correlated information. [Ref. l:p 6] 

2. History 

The MTACCS Master Plan of 1979 was the source for much of the history 
contained in this section. Figure 2 shows the evolution of the MTACCS component 
systems from 1%9 to the present.' 

The MTACCS concept first started in 1964, when the Commandant of the 
Marine Corps (CMC) tasked the Coordinator, Marine Corps Landing Force Development 
Activities ^ to act as the contracting technical representative for the conduct of Marine 



' In the figure, boxes with heavy borders denote systems that have been fielded. A 
detailed description of these systems is contained in Chapter ID. 

^ The Marine Corps Landing Force Development Activities was redesignated Marine 
Corps Development and Education Command (MCDEC). MCDEC was later reorganized 
into the Marine Corps Research, Development, and Acquisition Command (MCRDAC) 
and the Marine Corps Combat Development Command (MCCDC). 
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MTACCS Evolution and Mutations 
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"igure 2: MTACCS Evolution and Mutations [Source: MCCDC] 
tactical co mm and and control studies by Informatics, Inc. and the Stanford Research 
Institute. A further task was to recommend provisions to ensure compatibility with other 
service and international service systems to be operational when MTACCS was fielded. 
The Informatics, Inc. study developed a technical system concept and an implementation 
concept. The technical system concept had five functional areas that included: 



1. Tactical Combat Operations (TCO) 
Tactical Air Operations (TAO) 



2 . 
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3. Marine Integrated Fire and Air Support System (MIFASS) 

4. Marine Integrated Personnel and Logistics (MIPLOG) 

5. Communications (Comm) 

Informatics proposed the establishment of a test bed consisting primarily of off the shelf 
items and currently available test equipment. The Stanford Research Institute defined and 
quantified the tactical command and control requirements. 

On 16 February, 1969, the Naval Electronic Systems Command (NAVELEX)^ 
was designated the Principle Development Activity (PDA). In June of 1969, the billet 
of MTACCS project coordinator was established in the office of the Director, 
Management Analysis Group. The mission of this MTACCS coordinator was to monitor 
and coordinate the entire MTACCS project through its development and system 
integration. In August of 1969, the Marine Corps Development Center was tasked to 
provide prototype definition, systems effectiveness analysis, and subsequent operational 
system development. 

By August 1972, the test bed at Camp Pendleton, California had been 
completed and full scale evaluation of MIFASS had started. MIPLOG had evolved into 
two systems, the Marine Integrated Personnel System (MIPS) and the Marine Integrated 
Logistics System (MILOGS). In 1973, the TAO was redesignated Marine Air Command 
and Control System - 85 (MACCS-85). The Position Location Reporting System (PLRS), 
Tactical Warfare Analysis and Evaluation System (TWAES) and Tactical Exercise 

^ NAVELEX later became Space and Naval Warfare Systems Command (SPAWAR). 
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Simulator and Evaluator (TESE) were added to the concept, bringing the total number of 



systems to ten. 

In October of 1973, responsibility for the coordination of MTACCS was 
transferred to the development branch of the Research, Development, and Studies Division 
at HQMC. Less than two years later, a HQMC command and control systems 
coordinating committee was established with membership from each principle HQMC 
office concerned with the development and support of MTACCS and from MCDEC. 

The first MTACCS Master Plan was published in 1976. The issuing directive 
required that the plan be updated annually. About this time, the requirement for a 
dedicated MTACCS communications system was deleted, and TWAES and TESE were 
combined into Tactical Warfare Simulation, Evaluation, and Analysis System (TWSEAS). 

The Technical Interface Concepts were published in 1978 and provided basic 
inter/intraoperability criterion. [Ref. 3: pp 1-5 - 1-9] 

In September 1979, the MIFASS contract was awarded to Norden Systems 
Incorporated for a projected cost of $44 million and a delivery date of October 1982. The 
following year, new Marine Corps standards were published in the Tactical Interface 
Design Plan (TIDP). This resulted in a requirement for a Unit Level Message Switch 
(ULMS), a significant increase in software documentation, and a $14 million increase in 
costs. After the Assistant Commandant of the Marine Corps (ACMC) was notified by 
SPAWAR that Norden would have a problem in meeting the delivery deadline, the 
ACMC decided to delete four requirements, defer eight others, and delay the delivery by 
twelve months. Major General D. B. Barker and a panel of senior officers conducted a 
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study of the acquisition of MIFASS. Their results described a number of problems with 
the acquisition process, with the Marine Corps’ definition of requirements, and with a 
lack of consensus concerning doctrinal issues. Development continued with increasing 
costs and lengthening delays until MIFASS was finally terminated in May 1987 at a cost 
of $236 million.'* [Ref. 4,5] MACCS-85 was renamed the Tactical Air Operations 
Module (TAOM) and is currently being fielded. The PLRS system was also fielded. Due 
to the cancellation of MIFASS, the cornerstone of the original MTACCS concept, the 
remaining systems (TCO, TWSEAS, etc.) continued development but only nominal 
integration of these systems was attempted. MTACCS was revitalized in 1989 and an 
Operational Concept document was published in April of 1990. [Ref. 1] 



* This amount is based on a MIFASS chronology written by the last MIFASS ASPO. 
Several other figures have been published. In 1989, the GAO wrote "About $150 
Million" was spent on MIFASS. [Ref. 5:p 23] The great disparity cannot be resolved. 
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II. THE TERMINATION OF MIFASS 



A. INTRODUCTION 

1. Purpose of this Chapter 

The purpose of this chapter is to investigate the circumstances that led to the 
recent termination of a Marine Corps attempt to procure a command and control system. 
That system was called the Marine Integrated Fire and Air Support System (MIFASS). 
After nearly twenty years of development and an expenditure of more than $200 million, 
the program was terminated in 1987 while still in the full scale development phase. 

The remainder of this introductory section describes the MIFASS system, 
provides a brief history of MIFASS, and introduces the key players involved in the 
procurement of MIFASS, Section B provides several viewpoints and opinions on the 
possible causes of the termination. Section C attempts to sort through all of the varied 
opinions and arrive at a determination of the most significant factors that contributed to 
the cancellation of the program. 

2. A Description of the MIFASS System 

The Marine Integrated Fire and Air Support System (MIFASS) was a 
subsystem of the Marine Tactical Command and Control System (MTACCS). It was 
designed to operate directly or indirectly with the systems included in the MTACCS 
concept and with other services and NATO systems as well. [Ref. 3] MIFASS was a 
combination of equipment, personnel, and associated procedures. They were to provide 
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a means for exercising command and control (C^) of fire and air support assets within a 
Marine Air Ground Task Force (MAGTF). [Ref. 6:p D-3] MIFASS was to provide 
support in the immediate attack of targets of opportunity and to give automated assistance 
in fire planning, target intelligence, counter fire operations, nuclear and biological target 
analysis, forward area air defense, mission activity reporting, and low altitude airspace 
management. 

MIFASS centers were to be located at various levels within the MAGTF acting 
as the primary agency for the control of all supporting arms. Suites of equipment were 
to be constructed around a .set of software modules to enable a complete set of system 
capabilities. [Ref. 6;p 1-5] MIFASS software was originally designed to provide 
automation to assist the MAGTF in operating within a new tactical doctrine implemented 
by a system of Fire and Air Support Centers (FASC). The basic tenet of fire support 
prior to MIFASS and the FASC concept had been decentralization (Figure 3). The FASC 
concept was to reorganize and centralize the C? of fire support (Figure 4). The FASC’s 
were to assume the functions of both the Direct Air Support Center (DASC) and the Fire 
Support Coordination Center (FSCC), and selected roles of supporting artillery units and 
naval gunfire ships as well. [Ref. 6, 7:pII-2] The new FASC doctrine would employ 
MIFASS equipment to semi-automate both fire support coordination and air support 
coordination within one center. The established decentralized doctrine employed FSCCs 
to provide manual coordination of fire support and a DASC to provide manual 
coordination of air support. The change to a more centralized doctrine and the FASC 
concept was never officially endorsed or approved, but was supported by many key 
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decision makers in the Marine Corps. [Ref. 7;p D-3] This would later prove to be 
a key weakness of the MIFASS program. Although MIFASS was initially intended to 
support the more centralized fire support doctrine, the Marine Corps had great difficulty 
in its efforts to achieve a consensus acceptance of centralization. In the end, that 
consensus was never achieved. By 1983, the centralized doctrine and the FASC concept 
appear to have been abandoned. The problems that resulted from this lack of consensus 
are discussed in detail in Section B of this chapter. 

MIFASS equipment consisted of real-time display and information processing 
equipment capable of displaying friendly unit and target locations and of processing 
requests for fire and air support. This equipment was to be located in the FASCs and 
artillery Fire Direction Centers (FDC’s). Firing units would have small, hand held, off- 
line calculators to automate fire direction computations. Supporting arms observers would 
have been furnished Digital Communications Terminals (DCT) along with their 
manpacked radios in order to enhance communications with the FASC. The MIFASS 
concept envisioned supporting arms requests being routed simultaneously to the FASC 
in the area to be supported and the FASC who would control the unit providing the 
support. The senior FASC would clear the request by verifying friendly unit safety and 
conformance to other coordination, control, and limiting measures. Potential conflicts 
between ground and air support were to be coordinated laterally between FASCs. 

MIFASS was a very far sighted concept. The development of this program 
was an extreme challenge to the Marine Corps. It would take nearly a quarter of a 
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century for the program to run its course. The next section provides a brief history of this 
ill-fated project. 

3. MIFASS Chronology 

The following is an abbreviated summary of more than twenty years of 
MIFASS history. 



• 1964 - The Marine Corps hired the Stanford Research Institute and Informatics, Inc. 
to conduct Marine Tactical Command and Control studies. The results identified 
5 functional areas to be developed, one of which was MIFASS. 

• July 1967 - The fmst formal requirements documents describing MIFASS were 
published. 

• February 1969 - Naval Electronic Systems Command (NAVELEX, later it became 
Space and Naval Warfare Systems Command (SPAWAR)) was designated the 
Principle Development Activity for MTACCS (including MIFASS) by the Chief of 
Naval Material at the request of the Conunandant of the Marine Corps. 

• June 1969 - The Marine Corps established a charter for MTACCS which delineated 
the functions of the Headquarters Marine Corps (HQMC) staff and established a 
MTACCS Project Coordinator. 

• August 1969 - MCDEC was designated as the field agency test bed activity for 
MTACCS and was tasked to provide prototype definition, systems effectiveness 
analysis, and subsequent operational development. 

• 1972 - An MTACCS test bed was established at Marine Corps Tactical Systems 
Support Activity (MCTSSA), Camp Pendleton, Ca. The MIFASS concept was the 
first to be tested and was found to be a valid requirement for continued 
development, 

• December 1974 - In response to the test bed results, a MIFASS Required 
Operational Capabilities (ROC) was staffed, starting the formal acquisi- 
tion/development of the system. The ROC was approved and published in 1975. 

• March 1976 - A review of MIFASS design alternatives was held and it was decided 
to develop MIFASS with both the current organization and doctrine and with the 
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new organization (combine the DASC and FSCC into a FASC). This was not to 
be construed as approval of any organizational or doctrinal changes. 

• February 1977 - Approval was granted for full scale development of a MIFASS 
Engineering Development Model (EDM). The question of which organization and 
doctrine to use remained unresolved and development was directed to proceed with 
both. 

• September 1979 - A cost plus incentive fee contract was awarded to Norden 
Systems Incorporated (United Technologies Corporation). Cost projections were 
$44 million and a delivery date of October 1982. 

• July 1980 - Assistant Commandant of the Marine Corps (ACMC) Committee met 
and established a requirement for a Unit Level Message Switch (ULMS) and 
increased software documentation of MIFASS as a result of the new Marine Corps 
wide standards promulgated in the Tactical Interface Design Plan (TIDP). Projected 
costs increased to $58 million and the delivery date slid to April 1983. At this 
time, Norden was directed to change all subcontracts to fixed price contracts. 

• December 1982 - ACMC Committee was notified by the PDA that Norden would 
have problems in meeting the April 1983 delivery deadline due to problems in 
implementing the TIDP. The committee decided to delete four requirements and 
defer eight others. A developmental delay of 12 months was authorized. Major 
General D. B. Barker, DC/S for Training, chaired a study group formed at this time 
to review MIFASS requirements. Projected costs were $158.14 million with EDM 
delivery in April 1984. 

• May 1982 - Chief of StafFs Committee reviewed the Barker study and decided to 
continue development of the EDM using both doctrines and organizations. 

• July - December 1982 - The projected costs increased $14 million due to interface 
software for the Digital Communications Terminal (DCT), development of digital 
error correction, and to evaluate the feasibility of integrating the Tactical Combat 
Operations (TCO) System (another element of MTACCS). 

• June 1983 - The ACMC Committee convened to review two ADMs: 

1. Approval for a modification allowing a six month extension for the EDM 
delivery date. 

2. The requirement for ACMC approval prior to expenditure of more 
funds on MIFASS. 

The decision was also made to conduct Operational Testing II (OT-II) using only 
decentralized doctrine and organization. Work around for software changes was 
estimated at $3 Million. 
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• July 1984 - ACMC Committee granted an extension of five months for Engineering 
Development Model (EDM) delivery and approved a 50/50 cost sharing plan, 
proposed by Norden, of the $13 million for continued development. SPA WAR, the 
Principle Development Activity (PDA), was directed to negotiate a cap on the 
MIFASS development costs with the contractor. Projected costs are $135 million 
with a delivery date of March 1985. 

• May 1985 - The ACMC Committee met to modify MIFASS acquisition strategy. 
It was decided that a modified software package be completed with full capability 
included either in the MIFASS production model or in the Preplanned Product 
Improvement Model (P^I). It was decided that the delivery date of the system be 
extended thirteen months and an additional $7 million be expended. Projected costs 
were $210.88 million with a delivery date of April 1986. 

• October 1985 - During a status brief to the ACMC Committee, SPAWAR was 
directed to; 

1. Develop an acquisition plan based on competition for the production 
contract. 

2. Develop a finite list of required modifications. 

3. Complete a detailed R&D plan for MIFASS by task and year. 

4. Provide pros and cons of MIFASS as perceived by past and present First Marine 
Amphibious Force Test Directors. 

• March 1986 - The ACMC Committee received a proposed improved acquisition 
plan from the PDA, and the finite list of required modifications which totaled $19.8 
million. 

• May 1987 - the ACMC recommended to the CMC the termination of MIFASS. 
Tot^ funds spent on MIFASS exceeded $236 million. [Ref. 4] 



4. Key Players and Their Responsibilities 

No single individual was ever designated as the program manager for MIFASS. 
Program management was primarily accomplished through an Acquisition Coordinating 
Group. The Acquisition Coordinating Group was principally a decentralized assembly of 
personnel from HQMC staff sections and from the Marine Corps Development Center. 
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[Ref. 8] The acquisition organization used for the development of MIFASS is 
shown in Figure 5. 

a. The Acquisition Coordinating Group (ACG) 

This coordinating group consisted of action officer representatives from 
the Marine Corps Development Center, the HQMC Research, Development and Studies 
staff section, the Installations and Logistics staff section, and the Command, Control, 
Communications, and Computer Systems (C^ Systems) staff section. The functions of the 
group included: 

1. Write and execute the Acquisition Strategy Plan (ASP) and the Material 
Acquisition Process (MAP). 

2. Exchange information and coordinate actions of its members. 

3. Document program history. 

4. Recommend program management actions to the Acquisition Program Sponsor 
(APS) who was the Director, Command, Control, Communications, and Computer 
Systems. [Ref. 8:p 16] 

(J) Acquisition Sponsor Project Officer (ASPO). The leading member 
of the group was the Acquisition Sponsor Project Officer (ASPO) who was responsible 
for MIFASS systems acquisition. The ASPO was a representative from the program 
sponsor, the C^ Systems branch at HQMC. His primary duties included; 

1 . Coordinating staff action for the program sponsor. 

2. Ensuring the accuracy of the ROC and the Life Cycle Cost Forecast (LCCF). 
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Figure 5: MIFASS Acquisition Organization Diagram [Source: Authors] 
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3. Developing the ASP, MAP, and the Manpower Training Plan (MTP). 

4. Preparing the program objective memorandum (POM). 

5. Providing program action recommendations to the sponsor for approval. 
[Ref. 8:p 17] 

(2) Development Project Officer (DPO). The second key member was 
the Development Project Officer (DPO) who was responsible for the day to day 
management of the MIFASS development program. The DPO was a representative from 
the Development Center. His principle responsibilities were: 

1. To act as the single Marine Corps point of contact for tasking the Principle 
Development Activity (PDA). 

2. To prepare RDT&E work directives. 

3. To prepare Statements of Work. 

4. To provide program review briefings. [Ref. 8:p 17] 

(3) Acquisition Project Officer (APO). The Acquisition Project Officer 
(APO) was the third key member. The APO was a representative from the Installations 
and Logistics staff section at HQMC. His responsibility was for the management of the 
logistical, technical, and engineering aspects of production, fielding, operations, support, 
and retirement. His major responsibilities included: 

1 . Developing the Integrated Logistics Support Plan (ILSP). 

2. Assisting in the development of LCCF data to support program initiation and 
documentation. 
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3. Ensuring reliability, maintainability, supportability, and other logistical 
requirements are included in the system design. 

4. Assisting the ASPO in the programming of funds. [Ref. 8:p 16] 

(4) Development Coordinator (DC). The Development Coordinator 
(DC) was the final key member of the Acquisition Coordinating Group. The DC was a 
representative from the Research, Development, and Studies staff section at HQMC. His 
responsibility was to coordinate the MIFASS acquisition program. His major duties were; 

1. To maintain the master project file. 

2. To assist in the preparation of the ASP and the MAP, and the programming of 
funds. [Ref. 8;p 16] 

b. HQMC Staff 

The Commandant of the Marine Corps (CMC) was authorized to make 
the final Acquisition Category He (ACAT lie) decision of continuing or canceling 
MIFASS. The Assistant Commandant of the Marine Corps (ACMC) was designated the 
Acquisition Executive (AE). As AE he was required to monitor and control the 
acquisition development of MIFASS and report to the CMC. The AE had decision 
authority for funding and schedule changes for MIFASS acquisition. The ACMC chaired 
an ad hoc group of selected General officers called the ACMC Committee. The purpose 
of this committee was to act as a program review body, but not as a milestone review. 
As problems with MIFASS surfaced at an increasing rate, the Committee assumed many 
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of the responsibilities previously held by the Acquisition Program Sponsor (Director, 
Command, Control, Communications, and Computer Systems Division). [Ref. 8:p 16] 

c. Deputy Chief of Staff for Research, Development, and Studies 

The office of the Deputy Chief of Staff for Research, Development, and Studies 
was responsible for acquisition matters for ground combat systems from program 
initiation until the systems were ready for production. [Ref. 9:p 54] 

The Deputy Chief of Staff for Research, Development, and Studies 

(DC/S RD&S) acted as the Program Executive Officer (PEO)^ for MIFASS development 

up to Milestone III. His primary responsibilities included: 

1. Providing the Development Coordinator (DC) to the Acquisition Coordinating 
Group. 

2. Coordinating the review and approval of all MIFASS requirement documents. 

3. Ensuring a link between Mission Needs, Research Development, Test and 
Evaluation (RDT&E). 

4. Preparing Acquisition Decision Memorandums. [Ref. 8:p 18] 

d. Director, Command, Control, Communications, and Computer Systems 
The Acquisition Program Sponsor (APS) was the Director, Command, 

Control, Communications, and Computer Systems Division (DirC^SysDiv). His 
responsibilities included: 

1. Providing the MIFASS Acquisition Sponsor Project Officer (ASPO) to the 
Acquisition Coordinating Group. 

^ The Program Executive Officer (PEO) is generally described as a middle manager 
responsible for several separate programs. 
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2. Interoperability, intraoperability, and compatibility interface of MIFASS with other 
Systems. 

3. Reviewing all program initiations and requirements for MIFASS. 

4. Being the principle point of contact for management and planning guidance. 

5. Assessing the capability, suitability and cost of the program. 

6. Initiating the mission area analysis for MIFASS in determining operational 
requirements. [Ref. 8;p 19] 



e. The Deputy Chief of Staff for Installations and Logistics 

The office of the Deputy Chief of Staff for Installations and Logistics became the 
acquisition focal point during the production and development stages and throughout 
the remainder of the systems’ life cycle. [Ref. 9;p 54] 

The Deputy Chief of Staff for Installations and Logistics (DC/S I«&L) 

would have assumed the duties as the PEO had MIFASS reached the production and 

deployment phase. His major responsibilities included: 



1. Providing the Acquisition Project Officer (APO) who is a member of the 
Acquisition Coordinating Group. 

2. Planning and coordinating ILSPs up to Milestone IE. 

3. Ensuring reliability, availability, maintainability, and quality assurance were given 
due consideration during MIFASS development. [Ref. 8:p 18] 

/. The Marine Corps Development Center 

The Director of the Marine Corps Development Center (DirDevCtr) was 
subordinate to the Commanding General of the Marine Corps Development and Education 
Command (MCDEC). Although the Development Center was not directly subordinate to 
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the DC/S RD&S, there was an obvious need for close coordination between the two. 



The RD&S staff section was responsible for development policy within the Marine Corps. 
The Development Center implemented that policy. The major responsibilities of the 
director included: 

1. Providing the MIFASS Development Project Officer (DPO) to the ACG. 

2. Managing the Marine Corps Long Range Studies Program that generated a need 
for MIFASS, and submitting requirement documents to DC/S RD&S for HQMC 
staffing. 

3. Conducting Mission Area Analysis as requested. 

4. Acting as the single agency responsible for the management of work performed 
by the PDA and associated contractors. [Ref. 8:p 20] 

g. The Principle Development Activity (PDA) 

SPAWAR was the PDA for MIFASS and it’s mission was to support the 
Marine Corps by providing for the design, development, integration, test and evaluation, 
and procurement of MIFASS to satisfy operational requirements. SPAWAR managers 
received guidance and direction from CMC, but still reported to the Commander of 
SPAWAR. 

B. SEVERAL VIEWPOINTS ON THE TERMINATION OF MIFASS 
1. What Went Wrong? 

Many opinions on this subject have been published in the three years since the 
announcement of the termination and many people have addressed the question: "What 
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went wrong?". Not surprisingly, the.se numerous perspectives have offered varied, and 
sometimes conflicting, answers to that question. The termination of the MIFASS program 
can undoubtably be traced to many interrelated factors. In this section, the viewpoints 
and opinions of several key people, agencies, and groups will be examined. 

2. The Barker Working Group Study of MIFASS, 1982 

By late 1981, several MIFASS program perturbations had led to significant 
cost increases and schedule delays. Many key decision makers within the Marine Corps 
were developing serious doubts that the MIFASS program was still viable. The Assistant 
Commandant of the Marine Corps (ACMC) directed that a working group be established 
to revalidate the MIFASS requirement, determine cost effectiveness, and develop 
recommendations concerning the continuation of the MIFASS program. 
[Ref. I0:pp 2-4] This group was chaired by Major General D. B. Barker, USMC, 
and is referred to throughout this thesis as the Barker Working Group. 

By April of 1982, the working group had completed its evaluation. The report 

was very critical of the excessive size and weight of MIFASS. It stated; 

Easily the most significant problem associated with MIFASS is its impact on the 
mobility and survivability of maneuver command posts at every level. Although 
the Marine Tactical Command and Control System (MTACCS) Master Plan states 
that equipment size and weight must not exceed the transportation capability 
available to the using unit...there is little evidence of adherence to that guidance. 
[Ref. ll:p 22] 

Significant among the group’s conclusions was its declaration that "the 1979 
MIFASS Required Operational Capability (ROC) was invalid" [Ref. 1 l:p 38]. The group 
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found it necessary to submit its own ROC as a recommended replacement for the 1979 
ROC. Other key observations included: 

1. Despite years of test bed development, the government was not fully prepared to 
go to contract in 1979 because it had not clearly specified the functional flow 
diagrams which were to form the basis for software development. 

2. The contractor underestimated the complexity and difficulty of MIFASS software 
development. 

3. The Marine Corps organization for development is inadequate. [Ref. ll:p 27] 

Several courses of action were studied by this group. Among these were to 
continue the MIFASS program in accordance with the 1979 ROC, to significantly modify 
the program, or to terminate MIFASS and look elsewhere for a command and control 
system. Continuation of the program without modification was flatly rejected. Major 
modifications to the program were recommended including the merger of MIFASS with 
the Tactical Combat Operations (TCO) program and deletion of the FASC concept. 
[Ref. ll:p 41] The ACMC committee chose not to implement the study’s 
recommendations because they required major changes, and the belief at the time was that 
MIFASS was only six months away from operational testing [Ref. 8:p 37]. 

3. The General Accounting Office, 1983-1986 

During the period of 1983 to 1986, both the Congress and the GAO took a 
specific interest in the development of battlefield co mm and and control (C2) systems. 
At least five GAO reports reviewed Army and Marine Corps fire support C2 systems 
during these years. Generally, there was heightened interest by the Services, OSD, GAO, 
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and the Congress in clarifying the need to have both battlefield support systems, the 
Army’s Advanced Field Artillery Tactical Data System (AFATDS) and MIFASS. 
[Ref. 12;p 10] Marine Corps justification for MIFASS was AFATDS’ inability 
to integrate combined air/ground operations and its lack of a real time coordination 
capability with aircraft. 

In October of 1983, the General Accounting Office (GAO) reviewed both the 

Army’s and the Marine Corps’ efforts to automate their fire support command and control 

functions. The GAO report to the Secretary of Defense stated: 

The potential for common fire support command and control systems in the Army 
and the Marine Corps has not been exploited in spite of the Department of 
Defense’s (DOD’s) policies promoting standardized systems and equipment. 
Although the missions are similar and the fire support systems need to communicate 
with each other, each service is developing its own systems. This has led to 
possible duplication of development efforts and interoperability problems. 
[Ref. 13:p 1] 

This appears to be the first alarm being sounded that standardization is being 

ignored and that "possible duplication" exists. The GAO position was critical: 

Mission differences exist, and while these differences may constrain the degree of 
commonality, they do not preclude it... [Ref. 13:p 4] Neither service has explained 
why these differences require systems with totally unique hardware and software. 
[Ref. 13:p 6] 

The GAO opinion here has substantial merit. There are extensive similarities 
in the fire support procedures used by the Army and the Marine Corps. Marine Corps 
artillerymen are trained at the Army Artillery School at Fort Sill, Oklahoma. Marines use 
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several Army field manuals for artillery operations*. Much of the equipment and 
weaponry used is identical. While there are important, critical differences’, the 
significant degree of commonality in fire support procedures should not be overlooked. 

While this report states its case clearly and raises good questions, little 
attention appears to have been paid to it. If considerable duplication was taking place, 
it would seem to be only common sense that, sooner or later, one of the programs would 
become indefensible and the ax would fall. Secretary of Defense Mr. Caspar Weinberger, 
however, did relatively little during his tenure to constrain the requests of the services. 
[Ref. 14:p 123] Given the ever increasing defense budgets of the early 80's, the 
duplication was fiscally possible. If the Army and the Marine Corps wanted to go their 
separate ways, the barest of justifications was sufficient to gain DOD approval. It is 
doubtful this duplication was intentional. Redundancy is often the chosen method of 
ensuring survivability. In this case, however, redundancy may simply have been 
tolerated. 

4. The Institute for Defense Analyses (IDA), early 1987 

In July of 1986, the Under Secretary of Defense for Research and Engineering 
requested that IDA perform an independent assessment of the fire support command and 



* 6-20 "Combined Arms Operations", 6-30 "The Field Artillery Observer", 

FM 6-40 "Field Artillery Cannon Gunnery", and 6-50 "The Field Artillery Battery" 
are just a few examples. 

’ The Marine Corps has organic fixed wing fire support, for example, and plans for 
extensive employment of Naval gunfire. 
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control systems being developed by the Army and the Marine Corps. In his letter, he 
emphasized "Considerable momentum is developing to combine the two programs." 
[Ref. 15:p 1] In directing the IDA study, the Secretary of Defense, Mr. 
Weinberger, stated that DOD would "ensure maximum cross-service commonality and 
interoperability of these systems." [Ref. 16:p 1] Aside from any problems that 
either program may have been having, both Congress and the GAO had, by this time, 
long been questioning why the Army and the Marine Corps were both developing separate 
systems to do principally the same tasks. 

By early 1987, the IDA report had been completed. The intent of the study 
was to provide an independent assessment of the potential to consolidate the MIFASS 
and AFATDS programs [Ref. 12;p 7] The study examined the feasibility of three options; 

1. Both services field MIFASS. 

2. Both services field AFATDS. 

3. Army fields AFATDS and the Marine Corps fields MIFASS. 

The study first evaluated the ability of AFATDS to meet the needs of the 
Marine Corps without modification. The general finding was that, without modification, 
AFATDS would not meet the requirements of the Marine Corps as then stated. It further 
concluded that "Although it appears that AFATDS could be adapted to Marine Corps 
needs, this adaptability needs to be demonstrated" [Ref. 12:p 66]. While it was 
understood that AFATDS would require modification, the IDA study still painted a poor 
picture of MIFASS in three important areas: cost, weight, and interoperability. It stated; 
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MIFASS for the Army would weigh between two and five times as much as 
AFATDS...The variation in weight due to the uncertainty as to whether the Army 
would populate its centers with one string of equipment or two strings as the 
Marine Corps has planned. [Ref. 12:p 44] 

Five years after the Barker Working Group, MIFASS was once again declared 
to be too heavy. Also of major note is their finding that fielding a sufficiently ruggedized 
version of AFATDS to the Marine Corps would cost 

$285 Million to $355 Million less than fielding MIFASS, a savings of 65-80%. 
[Ref. 12:p 48] Worse yet, fielding MIFASS to the Army "could quadruple the cost of the 
Army program." [Ref. 12:p 64] From an interoperability standpoint, MIFASS would 
have little commonality with any of the other MTACCS Systems [Ref. 12:p E-20] At 
the present time, AFATDS is optimistically expected to reach full scale development in 
1992. [Ref. 5:p 13] 

The IDA report concluded that the Marine Corps should conduct an 
Adaptability Evaluation Program (AEP) to validate the concept of adapting AFATDS to 
the needs of the Marine Corps. This AEP could also help to validate potential cost and 
weight reductions. [Ref. 12;p 78] 

Assuming the results of the AEP are positive, the Marine Corps, in coordination 
with the Army, should supplement and modify the AFATDS software (in ADA) to 
implement the Marine Corps unique interfaces. The Marine Corps should select the 
Non-Developmental Item (NDI) equipment that most clearly fits its needs. 
[Ref. 12:p 82] 
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5. The Marine Corps Viewpoint, mid 1987 



a. Why Should MIFASS be Terminated? 

At the time that MIFASS was terminated, there were several groups and 
individuals within the Marine Corps that had direct input into the ultimate fate of the 
program. Many were convinced by now that MIFASS would not work and had been 
searching for reasons why it should be terminated rather than asking if it should be 
terminated. MIFASS still had support, however, and a strong consensus for or against 
was certainly lacking. While opinion on the fate of MIFASS was divided, each of the 
Marine agencies and commands had similar opinions on the performance of MIFASS 
during testing. The one theme that each appeared to express was simple: MIFASS did 
have the potential to enhance Fire Support C^ at higher levels of command, but it was of 
little value, and indeed inhibiting, at lower levels. Unfortunately, very little 
documentation exists containing the thoughts of the decision makers. Reliance must 
instead be placed upon several memoranda containing, primarily, the conclusions of the 
agencies briefing the Commandant at the final MIFASS review held on 1 1 May 1987. 

b. The Final MIFASS Review, 11 May 1987 

This section describes the presentations and opinions that were delivered 
by key participants at the final review of the MIFASS program. 

(I) The users perspective: Colonel W. A. Hesser. A key participant at 
the final review was Colonel W. A. Hesser, Commanding Officer, 7th Marines, whose 
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regiment was used in the operational testing. His conclusions, as summarized in a 
Memorandum for the Record were: 

1. MIFASS did not perform as well as the current manual system. 

2. MIFASS communications are inadequate. 

3. Reliability is unacceptable. 

4. Throughput and PLI (PLRS Location Information) is inadequate. 

5. Restricts mobility (Especially infantry battalion). 

6. Hard to learn and troubleshoot. 

7. Commander will not be tied to console because the console is not adequate for 
tactical decision making. [Ref. 17: Appendix B, Tab 2] 

Note the first deficiency. He does not state that MIFASS does not 
work, but only that it doesn’t work as well as the current manual fire support procedures. 
When asked by the Deputy Chief of Staff for Manpower to estimate the percentage of 
failure for MIFASS specific items. Colonel Hesser responded with 20%. While this 
would be high for an operational system, it is not so for an incomplete system that is still 
in the Full Scale Development phase. There was obvious concern that MIFASS would 
not provide a significant advantage over current methods. In a separate issue paper. 
Colonel Hesser conjectures on a reason for the MIFASS deficiencies: 

We decided to implement a new doctrine (the Fire and Air Support Center) along 

with the new system but changed our mind three years later. Simply, the Corps 

was never sure exactly what it wanted. [Ref. 18] 
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From Colonel Hesser’s viewpoint, MIFASS basically worked. He 
implied, however, that it was not what the Marine Corps needed for fire support 
coordination because of the doctrinal and organizational changes required to make it 
effective. Also, the existing communications equipment did not fully support the needs 
of the MIFASS architecture. In a nutshell, the Marine Corps got what it asked for, but 
not what it needed. This was, in part, because the Marine Corps changed course and 
turned back to the centralized doctrine with the FSCCs and the DASC instead of 
embracing the new FASC concept and a more centralized approach. 

(2 ) The I MAF Test Directorate. Directly above Colonel Hesser during 
the operational testing was the I MAF® Test Directorate. Their conclusion was that 
"Regiment and above FSCC’s and the DASC can be made to work satisfactorily." 
[Ref. 17:Appendix B] In order to make this feasible, they felt four things were required. 
Of these four, only two were MIFASS specific; a new computer, and software 
cleanup/modification. Their only other negative comment was that the equipment at the 
infantry battalion and fire direction center level was too heavy. Also, in their opinion, 
"MIFASS worked somewhat better than generally perceived by most observers" 
(separation of MIFASS specific problems from the problems of other systems is 
necessary). [Ref. 17: Appendix B, Tab 1] 



* I MAF is the First Marine Amphibious Force. MAF’s were redesignated Marine 
Expeditionary Forces (MEF’s) in 1987. 
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(3) Marine Corps Operational Test and Evaluation Activity ( MCOTEA ). 

The analysis of the Marine Corps Operational Test and Evaluation Activity (MCOTEA) 

is more critical of MIFASS. They state that: 

MIFASS does not enhance the control, coordination, and integration of fire support. 

In many respects, MIFASS inhibits the integration of supporting arms with the 
scheme of maneuver of the supported force. [Ref. 17: Appendix B, Tab 3] 

On the subject of operational suitability, they report that "MIFASS 
has a significant adverse impact on infantry mobility," and "MIFASS cannot be employed 
effectively in the current organization and does not meet the needs of the commander." 
[Ref. 17: Appendix B, Tab 3] It must be pointed out that the "current organization" being 
referred to is the decentralized doctrine using separate Fire Support Coordination Centers 
and Direct Air Support Centers. MIFASS was not intended to support this decentralized 
approach and had to be significantly reworked to make the attempt. 

(4) Required Operational Capability Working Group. Another group 
represented at the final review was the Required Operational Capability Working Group. 
While they were originally organized to determine just what the Marine Corps needed 
MIFASS to do, this is not apparent from their recommendations. The summary from the 
final review bears repeating here: 

The current system is not broke, organization and procedures are fundamentally 
sound and provide an adequate framework for an integrated air & fire support 
system. [Ref. 17: Appendix B, Tab 4] 

The ROC working group went on to say that while some assistance 
is needed in fire support, it is "primarily, doctrine and training." They recommended 
"limited organizational change -- additional capability for the regimental FSCC." 
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[Ref. 17; Appendix B, Tab 4] This clearly contradicts the FASC concept (combined semi- 
automated fire and air support coordination) that lies at the core of MIFASS. The group 
that was supposed to determine the requirements for MIFASS instead found that MIFASS 
was not necessary. 

(5) The Final Decision. Based on the information and opinions 
presented to him at the final review, the Commandant, General P. X. Kelley, decided on 
the following course of action: 

1. Terminate MIFASS. 

2. No immediate commitment to any Tactical Data System acquisition. 

3. Expand requirements review. 

4. New system definition study (evolutionary development). 

5. Pursue enhancements to equipment procurement. 

6. Deliberate participation in AFATDS. [Ref. 17: Appendix C] 

(6) The Embarrassment of MIFASS. Terminating the MIFASS program 
was embarrassing. Without a doubt, everyone concerned with MIFASS felt a sense of 
failure. As with any failure, questions were asked and fingers were pointed back and 
forth laying blame. There were significant problems with the operation of the MIFASS 
system during the testing. Even though many of the problems were not the fault of the 
contractor or MIFASS specific hardware/software, blaming the failure on the MIFASS 
system itself could make the cancellation decision more palatable. After the termination 
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of the program, it was certainly much more common to hear the phrase "MIFASS failed" 
than it was to hear "The Marine Corps failed". 

6. Space and Naval Warfare Systems Command (SPAWAR), 1987 

The last briefing at the final MIFASS review came from Space and Naval 
Warfare Systems Command. Highlights from their brief to the Commandant include: 

1 . The full MIFASS configuration was too complex a first step. 

2. The communications architecture used for the MIFASS EDM was high risk. 

3. The slowness of operation masks MIFASS functional utility. [Ref 17] 

On the subject of operational requirements, they "agree with the working group 
that decentralization/simplification was necessary. A single system solution is not 
necessary or desired." [Ref. 17] 

Within weeks of the cancellation of the MIFASS program. Space and Naval 
Warfare Systems Command (SPAWAR) published an overview of the program and 
lessons learned during the development. One of the key points made by this report was 
that: 

The MIFASS EDM generally met the requirements for which it was designed. The 
hardware units functioned as specified and were suitable for the tactical 
environment for which they were intended. The software generally functioned as 
intended. [Ref. 19:p 6-1] 

The liberal use of the word "generally" reflected SPAWAR acknowledgement 
of some technical difficulties, but none apparently that were considered to be major 
failures of the system. 
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The SPAWAR report is interesting because it does not specifically address the 
question: "What were the significant problems and failures of the MIFASS program?" 
If the system generally performed as it was designed, then what was wrong with it and 
why was it canceled? This appears to be another implied opinion that they got what they 
ordered, but not what they needed or wanted. The report gives a history of MIFASS and 
it implies that MIFASS development was poorly managed and, as a result, was 
excessively delayed and costly. Delays and cost increases, however, were an attribute of 
virtually every program at that time. MIFASS was not canceled because it was behind 
schedule and over budget. Although these are legitimate problems, the SPAWAR report 
fails to define the real factors that led to the termination of the MIFASS program. 

Another interesting asp>ect of this report is that it accepts no responsibility for 
any of the mismanagement it attributes to the program. Everything is either the fault of 
the Marine Corps or the contractor, Norden Systems. While it can certainly be argued 
that these two made mistakes, it is difficult to believe that the Principle Development 
Activity (PDA) is totally without fault, yet SPAWAR considered themselves blameless. 

There is an implication in the SPAWAR report that there were too many 
requirements changes and too many waivers approved. Indeed, there were many changes 
and the waivers did number at least 2(X). Were all these changes the problem, or were 
they attempts at correcting other problems such as poor initial requirements definition? 
Unfortunately, this question can not be answered within the scope of this thesis. It is not 
unreasonable, however, to conjecture that the waivers were a necessary effort required to 
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salvage a program in trouble, rather than a result of the simple inability of the contractor 
to perform. 

7. Current Perceptions, 1987 to the Present 

a. The Donald Geving Thesis 

In September of 1987, Captain Donald Geving, USMC, devoted his 
Masters Thesis at the Naval Postgraduate School to address the failure of MIFASS. Some 
of his background research has been quoted earlier in this thesis. His conclusions 
declared that three major areas doomed the MIFASS program: 

1 . Poor requirements definition. 

2. A flawed matrix organization. 

3. Interoperability problems. [Ref. 8:p 50] 

While his first and third conclusions appear to have merit, the emphasis 
that he places on the "flawed matrix organization" may be excessive. Was the 
organization itself a key contributor to the failure? Probably not. The next section will 
offer arguments that address why the organization was merely a hindrance to the program. 

b. Deputy Program Manager for MAGTF C? Systems 

Colonel Michael Stankosky, USMC, is the current Deputy PM for 
MAGTF C^ systems at the Marine Corps Research, Development, and Acquisition 
Command (MCRDAC) and was a member of the Research, Development, and Studies 
staff at the time of the final review of MIFASS. Colonel Stankosky has been quoted as 
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saying that we have failed miserably in the past because we have treated the development 
of command and control systems like building a tank, for example, where designers try 
to complete complex systems at once. Rather than develop a complex command and 
control system in one ambitious step, we should commit to a gradual development, with 
evolutionary improvements that can build upon smaller successes. [Ref. 20;p 27] 
This opinion is interesting becau.se it presents the idea that the problem itself is too big. 
A new systems engineering and acquisition methodology must be charted to solve the 
problem a little at a time. His position here, then, is that MIFASS failed because the 
Marine Corps tackled the problem all at once. There is some truth in this idea, to a 
point, but developing systems a piece at a time may invite interoperability problems if a 
well defined architecture is not established. 

C. IDENTIFYING THE PROBLEMS WITHIN THE MIFASS PROGRAM 

1. Why the Program was Terminated 

In May of 1987, the Commandant was faced with a MIFASS system that had 
real deficiencies. While some of his key advisors still had hope, others felt that the 
system was beyond help and no longer viable. Opinion was divided. Had no other 
reasonable alternative existed, the program probably would have continued with major 
modifications. An attractive alternative, however, did exist. 

By simply allowing the Army and the Marine Corps to both develop systems 
to do essentially the same tasks, the Defense Department was taking some risk. Though 
not a deliberate action, it was laying the foundation for the termination of one of these 



41 



programs. If one or the other were to experience major problems, or if the budget were 
to decline, this duplication of effort would become indefensible. When both of these 
conditions occurred, the loser was MIFASS. It is doubtful that this duplication was 
intentionally fostered in order to ensure at least one of the programs would be successful. 
It is more plausible that the Secretary of Defense was convinced of a legitimate need to 
pursue different courses of action due to the divergent missions and procedures of the two 
services involved. 

The IDA study broke the back of the MIFASS program. The Army’s 
AFATDS was shown to be superior in virtually every category of any importance. With 
the IDA study in hand, both the House and Senate Authorization Committees proposed 
to zero MIFASS funding in their versions of the fiscal 1988 Defense Authorization Bill. 
[Ref. 21 :p 110] Given the mounting Congressional and OSD pressure to cancel 
the program, there was only one rational conclusion that the Commandant could reach: 
recommend the termination of MIFASS and fall in with the AFATDS program. Under 
the circumstances of that day, MIFASS was properly and justifiably killed. The next 
question, then, is "Why did AFATDS look like a better program ?" Simply put, it was 
better because the Army made a few good key decisions and the Marine Corps made a 
few mistakes. The most significant of the Army’s good decisions was to develop the 
software for their AFATDS program first and the hardware last. The key advantage to 
this strategy is the availability of the newest technology when the time comes to decide 
on hardware. The process of developing software for MIFASS took several years. By 
settling on hardware first, the Marine Corps was guaranteed to have equipment that was 
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outdated before it was even fielded. This is obvious now, given a 20/20 hindsight, but 
the rapid pace of technological advances was not so obvious then. The most sensible 
approach, if there is an idea of the final architecture, is to proceed with software 
development as early as possible. [Ref. 22: p 8] 

2. The Problems Within the MIFASS Program 

a. Common Weaknesses in Defense Programs 

Several opinions on the MIFASS failure have been presented. Many of 
these viewpoints are one-sided perspectives that fail to see the "big picture". This section 
will sort through these opinions and draw some conclusions concerning which were the 
most significant of the problems. 

It has been established in study after study that there are weaknesses 
common to nearly every Defense program. J. Ronald Fox, a former Assistant Secretary 
of the Army responsible for procurement, lists the following trends as most significant: 

1. Setting requirements for the most sophisticated systems attainable, often 
irrespective of cost. 

2. Underestimated schedules and costs of major programs. 

3. Changes in program and contract requirements. 

4. Lack of incentives for contractors and government personnel to reduce program 
costs. 

5. Shortage of trained, quality personnel. [Ref. 14:p 32] 
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The MIFASS program is a textbook illustration of all of these common 
weaknesses, as well as several others. The following paragraphs provide evidence to 
defend this claim. 

b. MIFASS Tried to do too Much 

While MIFASS may not have been the "most sophisticated system 
attainable", there is some evidence that it was designed to do too much. Automation of 
some fire support tasks was a welcomed effort, but the designers of the system lost the 
support of the users when it was decided that MIFASS would accomplish many tasks that 
did not need automation. Many at the infantry battalion level were not amused that a 
heavy, resource guzzling system was being developed to automate tasks at their level 
that were being performed satisfactorily by the current manual method, 

c. Underestimation of Schedules and Costs 

As early as 1982, it was obvious to the Barker Working Group that the 
contractor had underestimated the complexity and difficulty of MIFASS software 
development. These poor estimations were directly responsible for the cost and schedule 
overruns. Norden Systems, however, does not bear the full burden for the lack of 
accuracy in their estimations. Norden was significantly handicapped by the lack of 
decisiveness within the Marine Corps concerning the application of the FASC concept. 
This wavering of requirements led to change after change. Norden apparently did not 
have the experience to predict this level of requirements changes. 
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d. Changes in Program and Contract Requirements 



Poor initial requirements definition was without doubt the most serious 

of the program deficiencies. Without a clear direction to pursue, the program changed 

course time and time again. New doctrine and procedures had not yet been formally 

sanctioned, yet a system was already being developed to support the new concepts. 

When the initial ROC was written, it concentrated far too heavily on 

technical requirements and failed to identify the needs of the Marine Corps in mission 

terms. This ROC was then replaced by another in 1979 which was also judged by the 

Barker Working Group to be without value. The simple lack of a valid, realistic 

requirements document was a devastating deficiency of the program. 

According to Lieutenant Colonel Louis L. Boros’, USMC; 

Nearly one third of the developmental costs of MIFASS can be attributed to the 
"better mousetrap syndrome"; that is, each time the Marine Corps transferred a 
project officer, his successor added to, or in some way changed, the original set of 
requirements. [Ref. 23:p 42] 

e. Lack of Incentives to Reduce Program Costs 

Little could be determined concerning the incentives for government 
personnel to reduce costs. Traditionally, few incentives exist, but no information was 
available to confirm that this was the case with MIFASS. 

The contractor had litde incentive, if any, to reduce costs. The initial 
MIFASS contract, accounting for a large portion of the funding, was a cost plus incentive 



’ Lieutenant Colonel Boros served as the Aviation C^ officer with the Proponency & 
Requirements branch of the MAGTF Warfighting Center. 
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fee contract. With the contractor guaranteed to recoup approved costs, they had no real 
need to attempt to keep costs down. This problem was recognized and all contracts after 
the initial one were written as fixed price. 

/. Shortage of Trained, Quality Personnel 

Colonel Hesser (CO of the regiment that tested MIFASS) drew particular 
attention to this factor in an issue paper that he presented to Major General R. "M" 
Franklin , USMC, DC/S, RD&S. His stinging comments declared that "during the past 
eight years of MIFASS development, not a single MIFASS acquisition project officer has 
been promoted... With a single, non-promotable officer at HQMC in charge of 
development, the Marine Corps simply was not dedicating sufficient assets to the 
problem". [Ref. 18] The lack of trained quality personnel was a key factor. The best 
Marines simply did not want to be acquisition project officers. There was widespread 
belief that an assignment in acquisition was a career setback that was difficult to recover 
from. In addressing this same issue in response to Colonel Hesser’s comments. Brigadier 
General R. R. Porter wrote "The acquisition field is not a lucrative one for the majority 
of officers because of the perception that it does not lead to promotion" [Ref. 24] 
The allegation that none of the MIFASS ASPOs were promoted enhances that perception 
making it even more difficult to dispute. 

g. Underestimation of the Complexity of the Task 

It was recognized that the MIFASS program would push the limits of 
technology. It was a farsighted concept intended to anticipate the needs of the Marine 
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Corps in the 1980’s. The Marine Corps relied on Stanford Research Institute, Informatics 
Inc., and Norden to provide realistic, competent estimates of the complexity of the task. 
It does not appear that the extensive software development necessary was fully understood 
or sufficiently stressed by these contractors. 

h. Lack of Consensus Concerning Doctrine 

When faced with complex problems that have few, if any, precedents, 
senior managers often rely on consensus building to determine the best course of action. 
In the case of MIFASS, achieving a consensus concerning doctrine proved to be rather 
difficult. One can only speculate on the cause of this difficulty. The complexity of the 
task was overwhelming. The centralization issue can sharply divide opinion. 

i. The Marine Corps Organization for Acquisition 

Most of the principles involved have asserted in some way or another that 
the matrix organization utilized to develop MIFASS was a poor system. While the matrix 
organization was clumsy and inefficient, to blame the failure of the program on the 
organization is short sighted. Certainly, the organization was weak, but the real problems 
of MIFASS were rooted in other issues. There was a stifling lack of consensus 
concerning doctrine. This lack of consensus may be partially attributable to the weakness 
of the acquisition organization. Captain Geving asserted in his thesis that the organization 
caused a "decision strangulation". This factor could have accounted for the great 
difficulty encountered in making the formal decision to accept the FASC concept and 
break cleanly with established decentralized procedures. Had the FASC concept been 
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fully agreed upon and had sound requirements been established at the very beginning, it 
is possible, but doubtful, that the weakness of the matrix organization alone would have 
resulted in major problems. 

For the most part, criticism of the Marine Corps acquisition organization 
focused on three claims; 

1. No one was "in charge". 

2. Management by committee was inefficient and ineffective. 

3. MIFASS suffered from "decision strangulation" because of the large number of 
people who could effectively veto decisions. [Ref. 25:p 134] 

"Management by committee" did appear to be a drawback. The lack of 
clear command channels was a problem typical of the majority of the defense acquisition 
programs prior to the Defense Reorganization Act of the late 1980’s. There is little 
evidence, however, to support the other claims. 

The most valid criticism of this organization would be that it was slow 
to react to the problems within the MIFASS program. Virtually insurmountable problems 
should have been obvious from the beginning. Recognizing and coping with these 
problems was a slow and tedious process involving a lot of people. But Marines did 
recognize the problems. Marines did recommend solutions and decisions were made to 
implement or ignore those recommendations. 

While day to day program management by committee may have been 
cumbersome there was certainly "someone in charge" from a big picture point of view. 
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Numerous Acquisition Decision Memoranda (ADM) were published outlining key strategy 
decisions. The correctness of those decisions, however, rested on the shoulders of the 
decision maker. Given the best advice in a timely manner, the decision maker can still 
make the wrong decision. The acquisition organization appears to have presented the 
decision makers with sufficient information to make the right decision. In many cases, 
choices were made that, given the benefit of hindsight, appear to have been wrong. 

Political pressures, cognitive bias, personal agenda, and parochial attitudes 
all could have contributed to those decisions. The impact of these factors is certainly 
difficult to assess, but they provide a likely explanation for making the "wrong" decision 
when given all of the information necessary to choose correctly. 

D. CONCLUSIONS AND LESSONS LEARNED 
1. Conclusions 

The Commandant of the Marine Corps made the correct decision in 1987. 
MIFASS was indefensible from a budgetary standpoint and it was not what the Marine 
Corps needed at the time. 

There were four key problems within the MIFASS program: 

1. A lack of consensus concerning the doctrinal issue of centralization versus 
decentralization. 

2. Unstable requirements definition that failed to state requirements in mission terms. 

3. Underestimation of the complexity of the task. 

4. Adherence to the traditional approach of concentration on hardware first and then 
the software. 
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The clumsy and inefficient management system was a hindrance to the 
program, but the only devastating problem was the lack of the foundation necessary to 
establish the program in the first place: sound initial requirements definition based on 
appropriate doctrine. 

The unfounded initial definition, and the failure to agree on doctrinal 
justification that followed, led to interoperability problems, cost increases, and program 
delays. By 1987, the MIFASS program was the victim of the Serengeti Phenomenon 
the slowest thing on the plain in the morning is breakfast and anything that limps, dies. 
MIFASS limped, AFATDS did not. 

2. Lessons Learned 

The Marine Corps has learned many lessons from the failure of MIFASS. The 
old matrix organization has been replaced with a dramatically different acquisition system. 
In response to the Goldwater-Nichols Reorganization Act of 1986, and the termination of 
MIFASS in 1987, the procurement business in the Marine Corps has been radically 
changed. A thorough description of this new acquisition organization is presented in 
Chapter HI of this thesis. 

Hopefully, a lesson has been learned concerning requirements definition. The 
recently published Marine Corps Directive on Acquisition drives the point home: 



The Serengeti Phenomenon was a term used by Radm Flanagan, USN, 
Superintendent’s Guest Lecturer, NPS, October 1990, in reference to the ill-fated Navy 
P-7 Anti-submarine Warfare aircraft. 
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The ROC should identify operational requirements not hardware solutions. It 
should provide a range of values vice a fixed point requirement. A poorly written 
ROC will overly constrain potential alternatives for meeting the operational 
requirements and will jeopardize the success of the acquisition program. 
[Ref. 26;p 9-5] 

It is unlikely that new Marine Corps systems will try to tackle so much at one 
time in the future. Wary of falling into that trap again, current Marine Corps philosophy 
embraces the ideas of modular, evolutionary acquisition using non-developmental items 
as much as possible. The "build a little, test a little, field a little" approach will be used 
to prevent another MIFASS from happening. Overall, the Marine Corps responded to the 
MIFASS failure in a big way. A description of that response follows in Chapter III. Will 
the response be sufficient to prevent further disappointments? That is one of the driving 
questions behind this assessment effort. 
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III. MTACCS TODAY: THE RESPONSE TO MIFASS 



A. INTRODUCTION 

The United States Marine Corps is a proud organization. The failure of MIFASS 
was not taken lightly. The response to that failure would be far reaching, but MIFASS 
was not the only factor. There were many contributing factors that, when summed 
together, virtually demanded a reorganization of the acquisition system. The Goldwater- 
Nichols Reorganization Act of 1986“, the embarrassment of MIFASS in May 1987, the 
appointment of a new Marine Corps Commandant, General Alfred M. Gray on 1 July 
1987, and the completion of a critical report by the Naval Research Advisory 
Committee‘S, were all key contributors. Together they forced sweeping organizational 
changes throughout the Marine Corps. 

Several initiatives were undertaken to strengthen the Marine Corps in its combat 
effectiveness and in its management of defense resources. The scope of these initiatives 
was rather broad, but some of the more important objectives can be summarized as 
follows: 

1. Revitalize the MTACCS concept to correct the deficiencies identified by both the 
MIFASS failure and the Naval Research Advisory Committee (NRAC). 

“ The Goldwater-Nichols Reorganization Act forced major changes on Defense 
acquisition. It is discussed in greater detail in Section E of this chapter. 

The NRAC report on Intra/Interoperability deficiencies within MTACCS is 
addressed in more detail in Chapter YE. 
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2. Reorganize the acquisition organization within the Marine Corps to capitalize on 
the lessons learned from MIFASS and to comply with the Goldwater-Nichols 
Reorganization Act. 

3. Implement several warfighting enhancement initiatives (such as the addition of a 
fourth rifle company to each infantry battalion). 

The numerous warfighting enhancement initiatives will have a significant impact 
on the requirements of MTACCS. They are mainly organizational and equipment changes 
designed to provide the most efficient distribution of Marine Corps assets. Assessment 
of these initiatives, however, is beyond the scope of this thesis. 

This chapter will focus on defining three key issues; 

1. The current MTACCS concept. 

2. A configuration management tool called the Field Development System (FDS). 

3. The current MTACCS acquisition and development organization and methodology. 

B. THE "REVITALIZED ” MTACCS CONCEPT 

1. The Need for Reevaluation 

In the past, MTACCS was defined as a "conceptual association of C^ systems 
to support tactical operations using where feasible, common equipment, operational 
procedures, databases, and design philosophy...." [Ref. 3:p 1-1] Exactly what that meant 
is unclear now and was probably unclear even to those who wrote it more than eleven 
years ago. To many people, "a conceptual association" meant that MTACCS subsystems 
were developed somewhat independently with little regard for interoperability and 
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configuration management. In fact, this appears to have been the majority belief. 
MTACCS was developed from the outset in just that way and serious deficiencies and 
setbacks ensued. By 1988, the program had ground virtually to a halt, MIFASS had 
been terminated. Congress had passed the Goldwater-Nichols Reorganization Act, and it 
appeared that the time had come to step back and reevaluate the entire MTACCS concept. 
As a result of this reevaluation, efforts have been undertaken to update the original 
MTACCS concept into the planned Marine Corps Command, Control, Communications, 
Computers, Intelligence, and Interoperability (C*!^) Architecture.'^ [Ref. 27:p 8] 

2. The Vision of General Gray 

A key objective of the new Commandant would be to develop a Marine Corps 
that is lighter "making both Marines on the ground and the gear in their hands more 
mobile and more lethal". [Ref. 28:p 15] 

In General Gray’s view, attrition, firepower, and frontal assault are no longer 
the key to combat success; superior technology, purposeful movement, the application of 
combat power at the proper time and place, initiative and the influence of commanders 
through their command, control, communications, and intelligence will allow Marines to 
engage any enemy and win. [Ref. 29: p 107] 

These ideas will have a significant impact on the development of MTACCS 
component systems. Someone once said "For every vision, there is an equal but opposite 

Quoting from Signal magazine, "In 1988, the Marine Corps merged the 
inextricably entwined, but often estranged, military disciplines - communications and 
intelligence. The Corps, acknowledging this as a "bold move", went even further by 
adding the seemingly intractable field of intelligence interoperability." [Ref. 29:p 107] 
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revision". While some may feel that user support for MTACCS will wane with General 
Gray’s retirement in June of 1991, there is evidence that MTACCS will continue to 
maintain its course. 

It is General Gray's belief that MTACCS decisions have been made based on 
the input of all of the senior leadership and he is confident that the focus of the Marine 
Corps will be maintained. [Ref. 28:p 16] 

3. The Definition of MTACCS 
a. The Difficulty of Definition 

Clear self expression is a trait that is dying in America‘s. The numerous 
documents and publications that describe both MTACCS and the Field Development 
System (PDS) are heavily crowded with a multitude of obscure terminology. The 
excessive use of acronyms, vague cliches, and "buzzword" phrases, significantly hampers 
any attempt at developing a thorough understanding. In his book Command. Control, and 
the Common Defense. Lieutenant Colonel C. Kenneth Allard, USA, echoed this opinion 
when he wrote "The writings by experts in the field of command and control can be an 
impenetrable thicket of buzzwords, jargon, and obscure usages." [Ref. 30:p 148] 
This problem remains ubiquitous. It is not merely a trivial nuisance. The simple lack of 
a clear, understandable program definition can be devastating to a project. With this 
limitation in mind, the "revitalized" MTACCS concept is herein defined. 



Paraphrased from Dr. Donald Abenheim, Naval Postgraduate School, 
12 January 1991. 
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b. Key Elements of MAGTF 

The Commandant of the Marine Corps has identified several key elements 
that are required to support the Marine Air Ground Task Force (MAGTF). These 
elements include: 

1 . The tactical command, control, communications, and intelligence (C^I) systems for 
Ground C^, Aviation, C^, and Combat Service Support C^. 

2. Approved C^ architectures that synthesize the placement and use of tactical 
Command, Control, Communications, Computers, and Intelligence (C“I) systems. 

3. Supporting communications equipment. 

4. Command, control, communications, and intelligence (C^I) systems aboard 
amphibious ships. 

5. Common hardware and software building blocks. 

6. Interoperability requirements and standards programs. 

7. A strong configuration management process that does not allow perturbations of 
the elements unless the impact on the whole is assessed. [Ref. 27:p 1] 

MTACCS is the "umbrella concept" intended to provide these elements 
to the MAGTF commander. [Ref. 27:p 2] 

c. The MTACCS Concept 

The MTACCS program will be pursued as a series of integration phases. 
Each phase will merge the numerous developing and disparate components and 
subsystems into a consistent system that achieves a predetermined level of integration. 
[Ref. 31] Instead of building MTACCS in one ambitious step, the Marine Corps 
will gradually build the system by making evolutionary improvements in computer 
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software and hardware during each phase. [Ref. 20: p 27] These integration phases will 
be called Field Development System events. FDS 1 is the first of these events. The 
Field Development System is described in detail in Section D of this chapter. 

The MTACCS Operational Concept Document was published on 3 April 
1990. That document "defines MTACCS, outlines the operational concept, describes 
MTACCS component systems, and provides a concept for development/acquisition". 
[Ref. 1] 

In the Operational Concept, MTACCS is defined as "the integration of 
separate automation assisted MAGTF Command and Control (C^) Systems which support 
tactical operations." [Ref. 1] It is important to stress that MTACCS is a concept only . 
It is the integration of component systems to allow those systems interoperability in order 
to provide integrated and automated support for MAGTF C^. [Ref. 32:p 3] 
"MTACCS will achieve interoperability among automated systems by utilizing a common 
family of data processing hardware, a common operating system and support software." 
[Ref. 33:p 1] MTACCS is an engineering effort to: 

1. Select common hardware and software. 

2. Select MTACCS architecture. 

3. Test the architecture. 

4. Manage the integration of the component systems. [Ref. 33:p 1] 

Rather than simply allow for a vague "conceptual association," MTACCS is expected to 
"integrate" the separate systems. Now the role of MTACCS is better defined. 
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Separate systems will be developed for each of the four functional 



areas: 

1. Ground C“: Tactical Combat Operations (TCO), Multi-service Advanced Field 
Artillery Tactical Data System (MAFATDS). 

2. Aviation C^: Marine Air Command and Control System (MACCS). 

3. Combat Service Support (CSS) C^: Marine Integrated Personnel System (MIPS), 
Marine Integrated Logistics System (MILOGS). 

4. Intelligence: Marine Air-Ground Intelligence System (MAGIS). 

Figure 6 depicts the MTACCS concept. The Tactical Combat Operations (TCO) system 
will be the hub of MTACCS and is the system intended for MAGTF command and 
control. As such, TCO is intended to be the system that integrates the component 
systems of MTACCS. 

d. The MTACCS Architecture 

Pacific Northwest Laboratories (PNL) is the system engineer and 
integrator for MTACCS. PNL is responsible for architecture development and 
implementation, system requirements definition and standards development, systems 
engineering and development, and configuration management. [Ref. 34:p iii] 

The proposed architecture has been defined in a draft hardware/software 
recommendation prepared by PNL. This architecture consists of four layers as shown in 
Figure 7. 

The hardware layer will be comprised of a family of computers whose varying 

capabilities will be matched against the varying needs of different echelon levels. 

MTACCS Common Application Support Software (MCASS) envelops the two 
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MARINE TACTICAL COMMAND AND CONTROL SYSTEM 




middle layers which consist of System Support Software and Command and Control 
Software and will be the foundation upon which MTACCS software will be built. 
System Support Software will provide a uniform development approach and will 
rely on Commercial-Off-The-Shelf Software (COTS) to the maximum extent 
possible. Command and Control Support Software will capitalize upon 
developments made by the Army’s CASS program. The Command and Control 
Applications Software Layer will contain those common applications that provide 
common functionality across two or more MTACCS nodes. It will be comprised 
of software developed by Air, Ground, Intelligence, and Combat Service Support 
programs. These applications fall under the umbrella of MTACCS software which 
will facilitate communications between the various applications and provide an 
overall battle situation picture for the command and control facilities of the 
MTACCS. 
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Figure 7: MTACCS Four Layer Architecture [Source: Ref. 34] 



An important goal of the MTACCS philosophy is to develop common software 
for levels two and three, and common application software for each functional area 
at level four. The end result of the common building block approach for MTACCS 
is to lower development and production costs, enable common training and 
maintenance, lower support costs, reduce complexity, and increase interoperability. 
[Ref. 34:p 2.3-2.4] 



C. THE CURRENT STATUS OF MTACCS COMPONENT SYSTEMS 
1. MAGTF C^ 



The capstone of MTACCS will be the system which provides integration of 
all the other component systems. At the current time, such a system does not exist. 



although it is conceived to be a derivation of the Tactical Combat Operations (TCO) 
system. The TCO system is currently in the conceptual stage and will receive much of 
its definition through the Field Development System (FDS). [Ref. 2;p 1-6] The 
anticipated TCO development schedule is shown in Figure 8. 
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Figure 8: TCO Development Schedule [Source: Ref. 32] 



TCO will provide MAGTF commanders at all echelons with specific tactical 
applications software programs which will build on common hardware and software. 
These applications will include tools such as: 

1. Display of Position Location Information (PLI) extracted from PLRS/GPS 
systems. 
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2. Information on the friendly situation and resources extracted from the MIPS and 
MILOGS systems. 

3. Information on the supporting arms situation extracted from the Multi-service 
Advanced Field Artillery Tactical Data System (MAFATDS) system. 

4. Summary information on the enemy situation extracted from the MAGIS system. 
[Ref. 32;p B-1] 

2. Ground 

The major component systems of Ground include the Tactical Combat 
Operations (TCO) system and the Multi-service Advanced Field Artillery Tactical Data 
System (MAFATDS). At this level, TCO will primarily support infantry, tank, engineer, 
and reconnaissance units while MAFATDS will support the fire support units (artillery, 
mortar, and naval gunfire). TCO is still in the conceptual stage. The focus of TCO will 
be the development of a coihmon situation picture to support ground combat unit 
commanders and operations personnel. MAFATDS is a proposed adaptation of the Army 
Advanced Field Artillery Tactical Data System (AFATDS). AFATDS recently underwent 
a concept evaluation and is currently undergoing further development by the Magnavox 
Electronic Systems Company. [Ref. 2:p 1-6] The General Accounting Office reported in 
1989 that: 

Fielding AFATDS...is scheduled for the fourth quarter of fiscal year 1992. ..the 
schedule appears to be optimistic considering the significant software development 
still required... .[Ref. 5:p 13] 

MAFATDS is expected to be fielded in the 1994 time frame. Currently, Fleet 
Marine Force (FMF) units have an interim system, FIREFLEX, which will be used until 
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MAFATDS becomes available. [Ref. 2;p 1-6] The anticipated MAFATDS development 



schedule is shown in Figure 9. [Ref. 32: p B-2] 
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Figure 9: MAFATDS Development Schedule [Source: Ref. 32] 



3. Aviation 

The major component systems of Aviation include the Advanced Tactical 
Air Command and Control Central (ATACC), the Tactical Air Operations Module 
(TAOM), the Improved Direct Air Support Center (IDASC), and the Marine Air Traffic 
Control and Landing System (MATCALS). [Ref. 2:p 1-7] 

ATACC is being developed to support the operations and planning functions 
of the Tactical Air Command Center (TACC), the senior Marine aviation combat 
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operations center in the MAGTF. The TACC exercises command over MAGTF air 
operations, generates daily air tasking orders, plans the air campaign, and is the principle 
MAGTF interface with joint and combined agencies [Ref. 32:p B-3]. ATACC is 
scheduled to be available in 1992 [Ref. 2;p 1-7]. The anticipated ATACC development 
schedule is shown in Figure 10. 
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Figure 10: ATACC Development Schedule [Source: Ref. 32] 

TAOM is currently in production and has been designated to replace the 
AN/TYQ-2 and AN/TYQ-3A‘^ at the Tactical Air Operations Center. TAOM is capable 



The AN/TYQ-2 and AN/TTQ-3A are communications and computer 
components of the TAOC. 
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of performing all operational air defense tasks and is currently deployed in Saudi Arabia 
in support of Operation Desert Storm. 

IDASC is designed to support the Direct Air Support Center (DASC) tasks of 
coordinating assault support, close air support strikes, and air reconnaissance missions 
with other fire support means. The DASC product improvement program will incorporate 
selected automation measures to improve system performance. Phased improvements to 
IDASC include: 



1. Electronic mapping capability, i.e., replacement of paper map-manual plot with 
electronic projection map and electronic automated assistance (computer) plot. 

2. Status board automation, i.e., replacement of plexiglass status boards (one dealing 
with fixed wing and the other with rotary wing) and manually transcribed data 
information/updates with electronic displays at appropriate operator stations (fixed 
wing status display/rotary wing status displays) and electronic automated 
assistance input control devices (computers) to control fixed and rotary wing status 
input/display. 

3. Automation of the Air Tasking Order (ATO) to include receipt, dissemination, 
update, etc. 

4. Automation assistance for receipt of digital (DCT type) messages (Tactical Air 
Requests (TAR), Helo Requests (HR), etc.) 

5. Automatic incorporation of Position, Location, Reporting System (PLRS) data into 
the DASC electronic map/projection system. 

6. Automated assistance in journaling, recording traffic, printing, etc. 

7. Downsizing (transitioning to lighter equipment and smaller mobile shelters). 
[Ref. 2:p 1-7] 



The product improvement schedule is shown in Figure 11. 
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Figure 11: IDASC Product Improvement Schedule [Source: Ref. 32] 

4. Combat Service Support 

The major component subsystems of Combat Service Support C^ include the 



Marine Integrated Personnel System (MIPS), the Marine Integrated Logistics System 
(MILOGS), and the Improved Force Automated Services Center (IFASC) [Ref. 2]. 

MIPS will provide the FMF commanders essential near real time personnel 
information through its interface with TCO. MIPS will employ the Unit Commander’s 
Personnel System (UCPS) as the source of data to provide to TCO and the MAGTF C^ 
system. UCPS is currently available and being used by FMF units. The MIPS interface 
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with UCPS and TCO is conceptual and will be developed throughout the FDS series. 
[Ref. 2] The MIPS anticipated development schedule is shown in Figure 12 
[Ref. 32:p B-5]. 



FY 1990 


1991 


1992 


1993 


1994 


QTR 2 3 4 


12 3 4 


12 3 4 


12 3 4 


12 3 4 


MIPS 


FDS-1 


FDS-2 






Core Definition - — — 










Core Protocol Eval 










Core Development — « 











Core Test 










ASU -Core 










Core IOC 










Core FOC 








2003 



Figure 12: MIPS Development Schedule [Source: Ref. 32] 



MILOGS will employ the LOG II AIS'* systems and integrate their output 
to provide the information required by TCO and the MAGTF system. LOG II AIS 
systems currently exist and are being used within FMF units. The MILOGS interface 
with LOG n AIS and TCO is also conceptual and will be developed throughout the FDS 
series. The ongoing U.S. Army Combat Service Support Control System (CSSCS) 

The second generation automated logistics information system. 
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development is being closely monitored. Maximum advantage of Army development 
efforts will be taken in defining and developing MILOGS and will be incorporated into 
the FDS series. It is anticipated that the CSSCS development schedule will not permit 
the use of CSSCS functionality in FDS 1. [Ref. 2:p 1-7] The anticipated MILOGS 
development schedule is shown in Figure 13 [Ref. 32;p B-5]. 
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Figure 13: MILOGS Development Schedule [Source: Ref. 32] 



5. Intelligence 

The Intelligence Analysis System (IAS), currently under development, will be 
incorporated into FDS 1 and following FDS events as appropriate. Interfacing to the IAS 
will be facilitated for FDS 1 since the computer hardware, tools, etc., upon which the IAS 
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are hosted are the same basic building blocks that will be utilized for TCO, MIPS, and 
MILOGS. IAS serves as the fusion center for the multiple intelligence sources available 
to the MAGTF. 

Intelligence systems and agencies that provide input to the Intelligence 
Analysis System/Intelligence Analysis Center (lAS/IAC) are shown in Figure 14. 
Included are the Technical Control and Analysis Center (TCAC), Tactical Electronic 
Reconnaissance Process and Evaluation System (TERPES), Topographic platoon. 
Reconnaissance units (Force and Division), the Imagery Interpretation Facility (IIF), 
Imagery Processing (IP) segment. Remotely Piloted Vehicle (RPV) system. Interrogator 
Translator Teams (ITT), Counter Intelligence Teams (CIT), Joint Service Imagery 
Processing System (JSIPS), Remote Ground Sensors/Tactical Remote Sensor System 
(RGS/TRSS). 

The interaction between IAS and TCO is conceptual at this time and will be 
defined and developed during the FDS series. [Ref. 2;p 1-7] The anticipated IAS block 
upgrade development schedule is shown in Figure 15. [Ref. 32: p B-4]. 

6. Communications 

The MTACCS Master Acquisition Plan identifies several communications 
systems that are of vital importance to the success of MTACCS; 

1. AN/PSC-2 Digital Communications Terminal (DCT). A light weight, handheld, 
programmable message processor that plugs into standard Marine Corps Radios. 

2. Position Location Reporting System (PLRS). A system of digital UHF radios that 
will automatically provide commanders with accurate, near real time identification 
and location data on assigned forces. 
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Figure 14: Marine Air/Ground Intelligence Systems [Source: Ref. 32] 



3. Global Positioning Systems (GPS). A spaced based radio navigation system that 
provides position, velocity, and time. 

4. Unit Level Circuit Switch (ULCS). A family of digital equipment that provide 
automatic switching service and subscriber service functions. 

5. Unit Level Tactical Data Switch (ULTDS). A team transportable, 12 line data 
switch. 

6. Single Channel Ground Air Radio System (SINCGARS). A VHF-FM single 
channel, frequency hopping radio used to transmit voice and data. 

7. AN/MRC-142. A secure, VHF, digital, multichannel radio for voice and data. 

8. AN/TRC-170. A SHF troposcatter multichannel radio. [Ref. 21] 
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Figure 15: IAS Development Schedule [Source: Ref. 32] 

All but the ULTDS are in production. These systems are intended to provide 
the necessary communications throughput to sustain at least early versions of MTACCS. 
It is recognized that the capabilities of these systems may be exceeded as the MTACCS 
integration matures. 

The anticipated communications architecture is shown in Figure 16. 
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Figure 16: MTACCS Communications Architecture [Source: Ref. 34] 
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D. THE FIELD DEVELOPMENT SYSTEM (FDS) 



1. Background 

MTACCS was defined earlier as an "engineering effort" intended to 
accomplish, among other objectives, management ^ the integration ^ MTACCS 
component systems . The Field Development System project is a key component of that 
engineering effort. 

The Field Development "System" would perhaps be better described as a 
"process" or "methodology". FDS is based on promoting a strong working relationship 
between the FMF user. Marine Corps developers, and private industry. [Ref. 35;p iii] It 
is a strategy for including the user in the process of identifying and validating 
requirements for an integrated command and control automated support system. 
Figure 17 details the FDS approach. As shown in Figure 18, FDS will be a series of 
events. Specific goals will be established for each FDS event. During that event, the 
available version of all component subsystems will be brought to the FDS site. The 
systems will be integrated to the level necessary to achieve the objectives of that event. 
Once those objectives are achieved and the system is evaluated to be ready, a working, 
integrated system is delivered to the fleet users. Colonel Michael Stankosky, the current 
deputy program manager for MAGTF Command and Control Systems, feels that the 
evolutionary design of the system will allow the Marine Corps to deploy basic versions 
of MTACCS early on. Information from field testing will help designers overcome errors 
and technical difficulties by gradually building upon successes. [Ref. 20:p 27] The 
Marine Corps Tactical Systems Support Activity (MCTSSA) at Camp Pendleton, 
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Figure 17: FDS Approach [Source: Ref. 32] 
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Figure 18: FDS Evolutionary Strategy [Source: Ref. 32] 
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California, has been selected as the site for the first event, FDS 1, scheduled to be 



conducted in early 1991 [Ref. 2]. 

2. Guidance Framework 

In order to assure long term value and consistency between each Field 
Development System event, a Guidance Framework has been established prior to initiation 
of FDS 1. Key elements of the Guidance Framework are: 



1. Common software foundation from industry as the baseline information system 
architecture. 

2. Initial command software functionality for FDS 1 to include suitable items from 
emerging USMC programs. 

3. Leverage from industry hardware specifically to support USMC requirements. 

4. Application and integration software development only as deemed essential to 
furnish the required command software functionality to be addressed in each FDS. 

5. Provide a consistent, but evolving system framework to support embedding 
disparate components and subsystems each with their various schedules and 
maturities. 

6. Institute direct FMF involvement and direction in the sequential and open system 
development environment. 

7. Provide an evolving system platform for developing interoperability approaches 
and resolving issues. 

8. Provide system support for examining technologies prior to selection and/or 
funding for inclusion in subsequent FDS phases. [Ref. 2:p ii] 
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3. Operational Concept 

The overall operational objective of FDS 1 is to provide operational personnel 
within the MAGTF with a set of automated tools and techniques that will assist them in 
performing already established functions. These functions have already been 
documented and proven over the years and are an accepted part of the command and staff 
process. Functionally, FDS 1 will put in place a system that will provide automated 
capabilities to commanders and staff officers in performing these doctrinal functions. 

In support of these objectives, the operational concepts employed in FDS 1 are 
simple. WHAT functions are performed and by WHOM will not be affected by FDS 1, 
only HOW the function is accomplished. What this means is that FDS 1 will concentrate 
on providing commanders and staff officers automated assistance in the form of 
computers, electronic displays, and digital communications to perform functions they are 
now performing manually. 

In this regard, FDS 1 will not initially try to achieve a wide range of 
"operational functionality" to support personnel, but rather will focus its efforts on 
putting the basic support functionality in place that will enable simple operational 
functions to be performed using automated equipment. The scope of the operational 
functionality will be incrementally expanded in future FDS phases to include all required 
command and staff functions deemed appropriate for inclusion in MTACCS. 

[Ref. 2:p 1-9] 
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4. Generalized Objectives 

The generalized objectives to be achieved at each FDS phase are: 

1. Present to users a functioning entity, not just disconnected technologies. 

2. Demonstrate leverage from available system components. 

3. Provide increasing experience and guidance opportunities in the growth of 
automated assistance. 

4. Provide fieldable system segments for USMC units. 

5. Build an evolving working model of MTACCS. 

6. Build models so that some enduring value is achieved at each FDS phase. 

7. Institutionalize a development approach that will enhance alignment with 
requirements and accelerate the delivery of capability to the field. 

8. Institutionalize a development approach that will facilitate integration of disparate 
developing technical subsystems. [Ref. 2:p iii] 

E. THE NEW MARINE CORPS ACQUISITION ORGANIZATION 

1. The Goldwater*NichoIs Reorganization Act 

The Goldwater-Nichols Reorganization Act "requires the military departments 
to designate a single office or entity in each secretariat to conduct acquisition functions 
to eliminate the parallel or duplicate acquisition offices that had existed in both 
secretariats and the services’ Chief of Staff organizations". [Ref. 26:p 2] This same 
guidance was applied to the acquisition organization within the Marine Corps. 

The Marine Corps complied with this act by creating two new commands: the 
Marine Corps Combat Development Command (MCCDC) and the Marine Corps 
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Research, Development, and Acquisition Command (MCRDAC). The Marine Corps 

Development and Education Command (MCDEC) was eliminated and its functions were 

distributed between the two new commands. 

Prior to this reorganization, acquisition responsibilities were divided among several 
headquarters activities. Most of the acquisition functions previously conducted by 
several different departments and divisions in Marine Corps Headquarters were 
centralized into the newly formed Research, Development, and Acquisition 
Command. [Ref. 9:p 54] 

2. The Marine Corps Combat Development Command (MCCDC) 

MCCDC has the responsibility of refining requirements that are identified by 
the Fleet Marine Force (FMF). Requirements may be satisfied through changes in 
doctrine, structure, tactics, or equipment. The Commanding General of this command 
assesses the FMF requirement in order to validate the need for the acquisition of 
equipment. If new equipment is needed to satisfy the requirement, the Warfighting 
Center (a component within MCCDC) publishes a statement of Required Operational 
Capability (ROC). The Commanding General of the Marine Corps Research, 
Development, and Acquisition Command uses this ROC as the basis to acquire the new 
equipment. [Ref. 27: p 30] 

The Marine Corps Systems Acquisition Management manual lists specific 
responsibilities of the Commanding General of MCCDC. These responsibilities include: 

1. Develop concepts, plans, and doctrine. 

2. Identify requirements for changes to doctrine, training, MAGTF force structure, 
and material. 

3. Serve as the MAGTF proponent. [Ref. 26: p 3-21] 
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The organization created to accomplish these tasks is depicted in Figure 19. 




Figure 19: MCCDC Organizational Diagram [Source: MCCDC] 

3. The Marine Corps Research, Development, and Acquisition Command 
(MCRDAC) 

The Marine Corps Systems Acquisition Management Manual describes the 
responsibilities of MCRDAC as follows; 

The Commanding General of MCRDAC is the Marine Corps Program Executive 
Officer (PEO). As such he has the responsibility, authority, and accountability for 
all Marine Corps acquisition programs in accordance with Public Law 98-94 
(Goldwater-Nichols Reorganization Act) ... [Ref. 26:p 3-13] 

The Program Executive Officer (PEO) is defined by the Secretary of Defense, 

Dick Cheney, in his 1989 report to the President on defense management. In that report. 
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the PEO is described as a key middle manager responsible to the Service Acquisition 
Executive (SAE) for defined and limited groups of major programs. The PEO will have 
a small, separate staff organization and devote full time attention to management of 
assigned programs and related technical support resources. [Ref. 36:p 9] The 
streamlined acquisition organization mandated by the Defense Management Review is 
shown in Figure 20. This streamlined approach was instituted with the intention of 
establishing clear command channels for the acquisition of new systems. An extract of 
the MCRDAC organizational diagram is shown in Figure 21. 




Figure 20: Streamlined Acquisition Approach for Major Programs [Source: 
Authors] 
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Figure 21: MCRDAC Organizational Diagram [Source: Ref. 26] 

The Commanding General of MCRDAC assigns program managers and issues their 

charters. 'The charter is a memorandum of understanding between the program manager 

and his superiors" [Ref. 37:p 2-6]. It details the precise scope of the program 

manager’s responsibility and authority [Ref. 37;p 2-5]. 

The appropriate program manager takes the validated ROC and turns it into a 
reality. The Commanding General of MCRDAC has the authority for overall 
MTACCS acquisition policy, accountability for acquisition execution, and clear 
lines of command for program managers... He has designated the program manager 
for Marine Air Ground Task Force (MAGTF) Command and Control as the focal 
point for MTACCS [Ref. 27:p 30] 
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Program managers have full authority, responsibility, and accountability for their 
programs. They report directly to the Program Executive Officer (PEO) for all 
programmatic matters, and are assigned the full authority of the PEO for the 
centralized management of specified acquisition programs. [Ref 26;p 3-16] 

The Marine Corps Systems Acquisition Management Manual lists thirty five 
specific responsibilities of the Commanding General of MCRDAC. These responsibilities 
include: 



1. Advises the Commandant on Marine Corps acquisition policy. 

2. With the Commanding General MCCDC, coordinates the implementation of Joint 
Service Programs (JSP) and Other Service Programs (OSP). 

3. Implements DOD/DON/USMC systems acquisition policy. 

4. Provides input into the PPBS for acquisition and RDT&E. 

5. Provides guidance to Program Managers in managing the business, financial, and 
technical aspects of assigned programs. 

6. Represents acquisition programs to HQMC, DON, OSD, and the Congress. 

7. Advises the Commandant at acquisition decision milestones and coordinates a 
number of review committees. 



F. SUMMARY 

Several problem areas were identified by the Marine Corps during the MIFASS era. 
Efforts to solve those problems have been extensive. The main thrust of these efforts has 
concentrated on a major reorganization of the Marine Corps development and acquisition 
team and a dedication to the strategy of Evolutionary Acquisition. The remainder of this 
thesis examines these solutions in detail. The objective is to develop an understanding 
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of the strengths and the possible risks inherent in both the MTACCS concept and the 
proposed solutions to long standing problems. 



84 



IV. A FEASIBILITY ASSESSMENT 



A. THE NEED TO QUESTION FEASIBILITY 

Since its inception, MTACCS has been considered to be a bold, farsighted concept. 
Developing a fully operational, effective command and control system of this scope will 
pose a major challenge to the Marine Corps. The risk of failure is significant. While 
supporters of the MTACCS concept are optimistic, there is considerable precedent to 
cause concerns; concern that the system may not be compatible with current doctrine; 
concern that the objectives may not even be technically possible at any reasonable cost. 
There must be, at the very outset, an assessment of the feasibility of this project. 

For the purpose of this thesis, feasibility is defined as the satisfaction of the 
following general criteria. To be feasible, MTACCS must be: 

1. Compatible with current doctrine and established procedures. 

2. Technically possible. 

3. Limited in complexity, not the most sophisticated system imaginable. 

4. Procured with an effective acquisition strategy. 

While these criteria have been chosen based on subjective determination, there is little 
doubt that they represent a collection of common sense factors vital to the success of the 
MTACCS project. 
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Many risk factors have already been identified and addressed within the draft 
MTACCS Master Acquisition Plan (MAP). Some risk factors, however, have not been 
presented. Others have been acknowledged, but not yet thoroughly explored. The effort 
of this chapter will be on developing a complete understanding of the risks involved in 
developing this command and control system in order to evaluate the likelihood of 
success. 

Much of the question of feasibility centers on risk analysis. Defining the idea of 
"risk" is crucial to this assessment. Several factors have been identified to qualitatively 
measure risk: 

1. To what degree is the anticipated technology available now? 

2. What is the extent of user advocacy? 

3. How well are the tasks involved defined and understood? 

4. What is the stability of the mission and the environment? 

5. What is the expected length of time to develop needed technologies? 

6. Are the procurement strategies tested? Appropriate? 

While this list is not exhaustive, these factors will provide some of the basis for 
determining how much risk is involved in meeting each of the feasibility criteria. 
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B. THE FEASIBILITY CRITERIA 



1. MTACCS must be Compatible with Current Doctrine and Established 
Procedures 

The warfighting doctrine of the United States Marine Corps provides the 

authoritative basis for the conduct of war by Marine forces. While authoritative, doctrine 

is not prescriptive [Ref. 38;p 44]. In the broad sense, doctrine is the foundation 

for the development of organizations and procedures. The command and control system 

includes these organizations and procedures as well as the communications and computers 

of automated decision support systems. It has been decided from the outset of the 

program that the MTACCS effort will not change current MAGTF staff and unit 

organizations [Ref. 32:p 3]. The doctrine that is the basis of the organization must be 

complimented by the concept that defines the decision support systems. 

It is a frequently cited axiom of systems analysis that information models the 
organization. An information system should model the structure of the 
organization. [Ref 39:p 57] 

2. MTACCS must be Technically Possible 

There is no doubt that the technical integration of numerous disparate 
automated systems across the entire spectrum of the battlefield will be a complex 
problem. There are many questions that must be answered as development of the 
MTACCS concept proceeds. The MTACCS Operational Concept implies several 
technical requirements. Among these are: 

1. Multi-level security. 
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2. Extensive data communications. 



3. Real time or near real time processing capability. 

4. Challenging software development. 



The technical feasibility of these requirements is difficult to assess. There are implied 
requirements that have not yet been completely defined. Still, a technical assessment can 
be made to develop an understanding of the general level of difficulty expected in 
achieving the goals of MTACCS. 

3. MTACCS must be Limited in Complexity 

It was pointed out in Chapter II that a common weakness of many defense 
programs is the desire to obtain the most sophisticated system available, regardless of cost 
and schedule delays. 

Robert R. Everett‘S has written: 

There is a normal human tendency to want more than is provided. We have, in 
fact, enormously greater technical capability than we had a few years ago but we 
cannot do everything, certainly not for a reasonable sum of money... If some 
elements of the system are over specified, over complex, and over expensive, some 
other elements may have to go without and the performance of the whole system 
may be limited by the weaker parts... A considerable amount of thoughtful work is 
now going on into C^ evaluation to help alleviate this problem, but it is one of great 
difficulty. [Ref. 40] 

To avoid this pitfall, MTACCS should be limited in complexity. Here, limited 
is defined as attempting to develop a level of sophistication that is sufficient to achieve 
desired goals yet obtainable within time constraints at reasonable effort. Admittedly, 



Robert R. Everett is a past president of the MITRE Corporation. 
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modifiers such as "sufficient" and "reasonable" are open to interpretation. The goal is not 
to establish rigid definitions, but rather to convey the idea that the problem must be 
approached in a practical manner, mindful of the time critical need for this system and 
of the fiscal austerity that looms in the future of MTACCS. 

4. MTACCS must be Procured with an Effective Acquisition Strategy 

The acquisition strategy determines the success or failure of a system. An 
effective strategy is one that provides an organized and consistent approach to meeting 
the program objectives within known constraints through an overall plan. 

C. ASSESSMENT OF MTACCS COMPATIBILITY WITH CURRENT 
DOCTRINE 

1. The Importance of Compatibility 

The MTACCS Operational Concept Document states "the MTACCS concept 
supports and is consistent with service plans and doctrine" [Ref. 1]. There has, however, 
been no formal assessment found in the numerous MTACCS documents (many in draft) 
that addresses the subject of compatibility with current doctrine and established 
procedures. The compatibility factor can be a significant contributor to the downfall of 
any program. It was clear that the MIFASS program was crippled by its incompatibility 
with "accepted" doctrine and procedures. It was intended to operate within a doctrine of 
centralization that was characterized by the Fire and Air Support Center (FASC) concept. 
When decisions were made to remain primarily with decentralized procedures or use a 
combination of both, MIFASS was no longer entirely compatible. Major rework was 
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necessary to try and force MIFASS to support a doctrine, an organization, and a set of 
procedures that it was not initially intended to support. The MTACCS concept, its goals, 
and its objectives must be compatible with the ideas of waifighting as practiced in the 
Marine Corps today. 

2. Warfighting Doctrine 

a. Doctrine 

Fleet Marine Force Manual 1, Warfighting , provides the authoritative 
basis for how Marines fight [Ref. 38;p i]. The manual establishes many of the guiding 
principles that Marines must use to achieve success in the conduct of war. Several key 
principles that are established by the manual will be discussed to provide a foundation in 
Marine Corps doctrine. 

b. Maneuver Warfare 

The Marine Corps concept for winning on the modem battlefield is a 
warfighting doctrine based on rapid, flexible, and opportunistic maneuver. It is through 
maneuver in both time and space, that a force can achieve decisive superiority at the 
necessary time and place. [Ref. 38:p 58] An emphasis on maneuver warfare implies a 
need for forces that are light, fast, and efficient 

c. Decentralization of Command 

The doctrinal issue of centralization versus decentralization was a pivotal 
factor on the failure of the MIFASS program. The support for decentralized control was 
stronger then and remains pervasive. FMFM 1 boldly asserts: 
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First and foremost, in order to generate the tempo of operations we desire and to 
best cope with the uncertainty, disorder, and fluidity of combat, command must be 
decentralized. That is, subordinate commanders must make decisions on their own 
initiative, based on their understanding of their senior’s intent... [Ref. 38;p 62] 

d. Implicit Communications 

Marine Corps doctrine promotes a reliance on the "human element" of 

command. Marine Corps philo.sophy must not only accommodate, but must exploit 

human traits such as boldness, initiative, personality, strength of will, and imagination. 

[Ref. 38:p 62] Along with this basic belief in the importance of the human element, the 

Marine Corps stresses the importance of "implicit communication". 

Implicit communication - to communicate through mutual understanding, using a 
minimum of key, well understood phrases or even anticipating each others thoughts 
- is a faster, more effective way to communicate than through the use of detailed, 
explicit instructions. [Ref. 38:p 63] 

A practical implication of this philosophy is that Marines should 
communicate orally when possible, because we communicate in how we talk; in our 
inflections and our tone of voice. [Ref. 38;p 63] 

e. Decision Making 

The making of competent and timely decisions is recognized as essential 
to victory in war. 

Whoever can make and implement his decisions consistently faster gains a 
tremendous, often decisive advantage. Decision making thus becomes essential to 
generating tempo. We should spare no effort to accelerate that decision making 
capability. [Ref 38:p 69] 
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/. Focus of Effort 



More than 300 years ago, Antoine-Henri Jomini proposed the idea of a 
"decisive point" of vulnerability. Victory could be achieved only by massing one’s forces 
against this decisive point. [Ref. 41] The idea of a "Focus of Effort" is a similar 
philosophy. 

Of all the efforts going on within our command, we recognize the focus of effort 
as being the most critical to success. All other efforts must support it. 
[Ref. 38:p 73] 

An important implication of this principle is the need for coordination and 
integration of forces to maintain a focus. 

g. Combined Arms 

The Marine Corps has long advocated the integration of combined arms 
in the conduct of war. 

In order to maximize combat power, we must use all the available resources to best 
advantage. To do so, the Marine Corps must follow a doctrine of combined arms. 
Combined arms is the integration of arms in such a way, that in order to counteract 
one, the enemy must make himself more vulnerable to the other. [Ref. 38:p 75] 

3. MTACCS Objectives that are Pertinent to Compatibility 

Several important objectives of the MTACCS concept impact on its 
compatibility with current doctrine. The MTACCS operational concept document outlines 
the following general objectives that are pertinent to compatibility: 

1, MTACCS must be as expeditionary as the force it supports. 

2. MTACCS must permit commanders to lead from where they are most needed. 
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3. MTACCS should not impede mobility. 

4. The communications architecture must evolve from a network of functionally 
dedicated voice channels into a system of digital information pipelines. 

5. MTACCS will provide a common user, centrally managed database. 

The first three of these listed objectives are entirely compatible with the 
doctrine that has been described. They demonstrate a recognition that the Marine Corps 
will operate in an expeditionary environment; an environment that mandates the capability 
to deploy rapidly and operate under austere conditions. The ideas of evolving 
communications and a centrally managed database, however, require investigation. Both 
imply the possibility of conflict with current doctrine. 

4. Compatibility Assessment 

a. An Evolving Communications Architecture 

Historically, there has been considerable difficulty establishing what 
information should be data and what should remain voice in a C^ system, [Ref 30:p 228]. 
While current Marine Corps doctrine emphasizes voice transmissions, face-to-face 
interaction, and "implicit communications", the objective of MTACCS appears to be 
aimed at significantly reducing voice traffic. This conflict can have important 
implications. A conflict with doctrine can cause division within the Marine Corps and 
a loss of user advocacy. 

The point is not trivial. In his book Command in War. Martin 
Van Creveld emphasizes the importance of informal communications: 
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... it is vital that the formal communication system be supplemented by an informal 
one that acts, so to speak, as lubricating oil. In any large organization, the virtues 
of formal communications systems - standardization, brevity, and precision - cannot 
be denied; those very virtues, however, also make such a system more subject to 
interruption and less flexible as a vehicle for original ideas... The danger that formal 
communications reduce command, and indeed thought itself, to trivia is a real one 
indeed. It must be guarded against by a design that deliberately leaves room for 
face-to-face, unstructured interaction... such exchanges represent the best way both 
of cutting down the total amount of communications that has to take place and of 
improving the quality of that communication. [Ref. 42:p 273] 

b. A Centrally Managed Database 

The centralization versus decentralization conflict was a contributor to the 
downfall of MIFASS. Since then, the Commandant has reemphasized the importance of 
the decentralization of command. A centrally managed database implies movement in a 
conflicting direction. It is true that a centrally managed database that is sufficiently 
replicated and distributed can support decentralized decision making. A complete 
assessment of this idea therefore, cannot be made. The particulars of the design and 
implementation of the centrally managed database have not yet been developed. The 
level and purpose of centralization continue to be an important concern in the future of 
MTACCS. 



c. Conclusions on Compatibility 

There continues to be considerable potential for doctrinal incompatibility 
within the MTACCS concept as currently stated. This compatibility problem can be 
averted but must be given appropriate attention in order to avoid a result similar to 
MIFASS. 
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The Field Development System concept document implies that doctrinal 



conflicts will be avoided since MTACCS will only affect how a task is performed and 
not ^ whom . This idea can help to avert the tendency towards centralization. If no 
changes are made in who makes the decisions, the system will tend to maintain a 
decentralized structure that reflects the current organization. Doctrine, however, also 
implies how something will be done, as has been shown. An emphasis on "implicit 
communications" implies voice transmissions, for example. 

The centralization issue is especially sensitive. The degree of 
centralization must be explicitly defined and accepted early in the program. Robert R. 
Everett has written: 

The potential for centralization that resides in modem technology creates great 
tension in the military structure. The designer says "Let’s provide the capability 
and argue about who does what later", but the local commander knows better. [Ref. 

40] 

D. ASSESSMENT OF MTACCS TECHNICAL FEASIBILITY 

1. The Need to Work Within Technical Reality 

Obviously, developers and contractors begin each new project with the belief 
that they can accomplish the task. They are optimistic. They have assessed the technical 
risks and judged them to be within reason. But this "judgement" is not infallible. It was 
shown in Chapter II that Norden Systems dramatically underestimated the volume and 
complexity of software necessary for MIFASS. This underestimation led them to believe 
they could build a system light enough to meet Marine Corps needs. When software 
requirements escalated, the hardware technology of the day was stretched beyond its 
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capacity. The hardware increased in size to handle the new processing requirements. 
Eventually, the sheer size and weight of the equipment became intolerable. It appears 
that processing fire and air support coordination in a box light enough and rugged enough 
for Marines was not possible given the technology limitations of that day. 

Several technical risk issues have been identified by program coordinators and 
contractors. The possibility of problems in the areas of multi-level security and 
communications capacity have been anticipated. The possibility of continued software 
development problems was not specifically addressed in the documents currently 
available. 

It is imperative that the MTACCS project assess the technical risk of 
implementing its goals. To that end, this chapter addresses three key technical questions 
that are derived from implied requirements: 

1 . Can current and projected communications systems meet the anticipated level of 
data communications? 

2. Will adequate multi-level security be achievable? 

3. What assurances are there that software development will succeed this time? 

The ability to answer these questions is restricted for several reasons. Many 
of the requirements, for example, have not yet been defined. Valuable insight, however, 
can be developed from a qualitative calculation of the technical feasibility of meeting 
implied requirements. 
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2 . Capacity of the Communications System 

In October of 1988, the Naval Research Advisory Committee published a 
report on intra/interoperability of Marine Corps command and control systems. That 
report stated in its executive summary: 

... it is unlikely that existing or planned tactical communications systems will have 
adequate capacity, connectivity, robustness, and multi-level security to support 
future battlefield information systems. [Ref. 43:p 3] 

They found that the Marine Corps had not done an up-to-date analysis to 
define in detail the communications requirements to support the MTACCS component 
systems [Ref. 43;p 33]. It appears that there continues to be a lack of detailed 
information in this area. The draft MTACCS Master Acquisition Plan states; "No data 
has been developed to bound the communications requirement for MTACCS. The 
evolutionary developing MTACCS will be a source of feedback requirements for the 
communications system for the procurement of greater digital handling capacity." 
[Ref. 32:p 3] 

The data requirements of MTACCS will, in all likelihood, quickly overwhelm 
the capacity of current communications systems. The Marine Corps expects this to 
happen. Specifics of the Marine Corps’ plan to counter this problem are not entirely 
clear. One can speculate that the Corps is watching closely the progress of the Army in 
addressing this same problem. The Army’s Tactical Command and Control System 
(ATCCS) will use some of the same tactical communications equipment that the Marine 
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Corps will use’*. ATCCS will more than likely have similar data flow requirements. 
The army plan will include deployment of packet switch appliques to circuit switched 
bearer systems to extend their communications capacity. [Ref. 44:p 181] 

An increase in the capacity of switching equipment alone, however, may not 
be sufficient. Much of the data traffic will continue to travel over single channel radio 
circuits, not a switched backbone. A switched backbone lacks the flexibility of single 
channel radio and it cannot completely supplant radio circuits. 

3. Multi-level Security 

The integration of the MTACCS component subsystems will require a 
capability for multi-level security. An operator utilizing the TCO system, for example, 
will have the capability of accessing several databases with varying levels of security 
classifications. 

As noted earlier, however, there is little confidence in the evaluation 
community that the systems available or in development will have a secure, trusted, multi- 
level capability. With the leaps and bounds technology continues to make at an 
accelerated pace, the era of secure trusted systems is not far away. William Barker stated 
in Signal magazine that: 

All the necessary trusted computer and cryptographic components exist, what 
remains is the secure integration of the trusted cryptographic control functions into 
workstation hardware and evaluation of the resulting information security 
workstations. [Ref. 45:p 59] 



* Both the Army and the Marine Corps are fielding SINCGARS equipment, for 
example. 
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There is currently a commercial device in development that has demonstrated 
the ability to allow classified and unclassified users to share the same network without 
compromising classified information. This system works on the basis of encrypting the 
classified information, thereby rendering it unintelligible to unauthorized users. This 
means that many types and classifications of u.sers can work on the same network without 
compromising classified information. This system, developed by Xerox, is reported to 
be able to turn any computer network into a network capable of handling classified data. 
[Ref. 46:p 92] Although this appears promising, the system throughput, after 
merging cryptographic functions with network level protocol functions, is still too slow 
for many user requirements and applications [Ref. 45:p 56]. 

There does not currently appear to be system capable of meeting the MTACCS 
requirements for information security if sensitive intelligence databases are to be an 
integrable part. The outlook is good for the future, but user confidence in secure, trusted 
systems must be cultivated in order for MTACCS to successfully integrate with the 
intelligence community. 

4. Software Development 

a. The Increasing Importance of Software 

Software has become the dominant factor in many of today’s military 
systems. This is especially true in command and control systems which tend to be very 
software intensive. An estimated 80-90% of the development costs of command and 
control systems can be attributed to software. [Ref. 47:p 92] 
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In the I960’s, CIS managers went by a rule of thumb that put the cost of computer 
hardware at about seven or eight times the cost of software. Since that time, 
software costs have risen steadily.. .during this same period, hardware costs have 
come down rapidly.. .thus the ratio between the cost of hardware and the cost of 
software has shifted dramatically. Today, software costs are estimated to be about 
ten times greater than hardware costs. [Ref. 39;p 33-34] 

Like most command and control systems, MTACCS will be software 
intensive. The development of MTACCS software will play a major role in determining 
the success of the program. 

b. The Crisis in Software Development 

While the capability of computer hardware has risen dramatically over 
the last decade, the capability of software has not kept pace. Major General Billy M. 
Thomas*’ was recently quoted in Army magazine as saying "the entire software industry 
is at the Model T Ford stage right now." [Ref. 48:p 36] Clearly, there is a low 
expectation of the current state of the software development art. 

The excessive schedule delays and cost overruns in software development 
projects throughout the Department of Defense have reached crisis proportions. "Experts 
are now saying that the chief military software problem may soon be that DOD cannot 
get enough of it - period." [Ref. 49:p 27] This problem affects everybody. 
General James S. Cassity Jr.“, USAF, wrote in 1988 ".. ask any program manager what 



Major General Thomas was the Commanding General of the U.S. Army 
Communications-Electronics Command at the time of the Army magazine interview. 

^ Commander, Air Force Communications Command in 1988. 
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his or her number one nightmare is today and the answer is software; it is the cause of 

most program delays." [Ref. 50:p 39] 

This crisis is not strictly a problem for the contractors to solve alone. 

Developers as well must take action to reduce the risk of software development failure. 

The report from a major software conference hosted by the Army's Communications 

Electronics Command (CECOM) in 1989 emphasized this point: 

Most of the current problems in software development are not technical in nature. 
They are management problems., .unfortunately, little attention has been paid to the 
software development process, which is often poorly controlled. 
[Ref. 51:p 5] 



In the development of MTACCS software, "management" is largely a 
responsibility of Marines; members of the three commands that together serve as the 
systems engineering management team. Marines must devote their fullest attention to the 
mitigation of software development problems. 

c. A History of Software Development Problems 

The MIFASS program was plagued with software problems, but MIFASS 
was not alone. Software problems are pervasive throughout the Department of Defense. 
General Bernard Randolph^', USAF, was quoted in Military Forum as saying "on 
software schedules, we’ve got a perfect record; we haven’t met one yet." [Ref. 49:p 29] 
Historically, software development in the military has been poor. 



Chief of Air Force Systems Command at the time. 
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d. How to Avoid the Software Development Dilemma 

Avoiding the software dilemma is not easy. Experts in the field of 
software development are optimistic, but they also realize that major modification of the 
software development process is necessary. Many of these experts have recommended 
methods of improving the chances of successful development. Those recommendations 
are outlined here: [Ref. 51 :p 8] 

(1) Buy rather than build. Barry W. Boehm^^ has written: 

Clearly, if you want to improve your organization’s software price-performance 
ratio, one major principle is "Don’t build custom software where mass produced 
software will satisfy your needs." [Ref. 52:p 43] 

(2) Build simpler products. It is an increasingly popular opinion that 
the only way to avoid excessive risk in the development of software is to settle for a 
modest software capability and see much of the capability of the hardware go unrealized. 
This opinion was colorfully presented in the SoftCon ’89 report published by CECOM: 

We also need some appetite suppressants for the users. If you have to go to the 
hospital, it is better to have a Ford on the road than a Mercedes-Benz half built in 
the garage. [Ref. 51:p 5] 

The growing software shortage means that the end user will have to moderate 
his demand for unrealized performance which has so driven complexity, experts 
contend. It will also mean buying more off-the-shelf software available in the 
commercial market. Traditionally, the services have failed on both accounts. 
[Ref. 49:p 31] 



“ Barry W. Boehm was the chief scientist in the Office of Technology at the 
TRW Defense Systems Group when this article was published in 1987. 
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(3) Use prototypes. Valuable experience and insight to the users actual 
needs, and not perceived requirements, can be gained from the use of prototypes. A 
software prototype should be considered just that; a prototype. A tool to help identify 
requirements and to ascertain feasibility. The prototype demonstrates what technology 
is actually capable of and how the objective system should behave [Ref. 51;p 5]. The 
prototype provides the base for the operational solution, but rarely is the prototype 
sufficient in itself to be considered the best solution, both in operational capability and 
life cycle costs, to the operational requirement [Ref. 5T.p 111]. 

(4) Involve the user in the requirements process. This is an idea that 
has been repeated continuously throughout this thesis and reference material as well. This 
is the only way to ensure that the system fielded is actually what the user wants and 
needs. The user does not have to be software literate in terms of design and engineering, 
but must be thoroughly proficient in his military occupation. Only by being thoroughly 
proficient can he ensure that the system will actually serve a useful role in the military 
environment. 

Another idea that has been repeated also applies: the use of 
incremental development. Incremental development coupled with frequent, competent 
user feedback has proven to be the most effective technique for fielding useful systems. 
[Ref 51:p 4] 

(5) Plan for Controlled Technology Insertion. Most current software 
development problems are not technical, but are management related problems. Not 
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enough attention has been paid to the software development process. Rather, the 
concentration has been on exhaustive testing of a particular product. [Ref. 51:p 5] 
Coordinating the upgrading of software incorporating new technology should be planned 
in advance to ensure the effectiveness of the system as a whole is increased. It is 
possible to add new technology into a system which greatly enhances the performance of 
a particular part, but the overall performance of the system is degraded. 

(6) Promote the use of standards. Standards improve our capability to 
communicate without hampering innovation. Standard interfaces and languages allow 
developers to concentrate on the program itself. Time and money is saved by not having 
to redevelop interfaces or work around software incompatibilities. [Ref. 51 :p 104] 

e. Current MTACCS Software Development Methodology 

Pacific Northwest Laboratories has been contracted as the system engineer 
and integrator for MTACCS. Their draft recommendations for the software components 
of MTACCS were based on several general criteria: 

1. Commonality. The recommended architecture should capitalize on developments 
made by the Army’s CASS^^ working groups and by Marine Corps C^ programs. 

2. Interoperability. Recommendations should focus on enhancing communications 
between C^ programs. 

3. Non-Proprietary. No recommendation will be vendor specific. 

4. Use of Non-Developmental-Items. No recommendations will rely on a product 
that has not been developed. 

Common Army Tactical Command and Control System Support Software. 
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5. Availability/Maintainability. Recommended components should be easily available 
from a number of different sources and should be well supported and maintained, 

6. Graceful Degradation. The overall architecture should provide sufficient 
redundancy so that loss of part of the system does not degrade the entire system. 

7. Supportability of Future Developments. Recommendations should not prevent 
incorporation of new equipment or ideas into the system. 

8. Recommendations should follow industry standards wherever possible. 
[Ref. 34:p 3.4] 

/. Assessment of Software Development 

It is clear that both the Marine Corps and its contractors are intent on 
implementing all of the generally accepted methods for averting disastrous problems in 
software development. Of the six recommendations listed earlier for avoiding software 
problems. Pacific Northwest Laboratories has specifically endorsed three as criteria for 
determining their software recommendations. The remaining three are expected to be 
implemented through the Field Development System (FDS). They are; 

1. Build simpler products. 

2. Use prototypes. 

3. Involve the user in the requirements process. 

These ideas, however, are still in their infancy. FDS-1 has not yet been 
demonstrated. Marine Corps’ intentions for software development are promising, but a 
more detailed assessment will not be possible until the system matures. 
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5. Conclusions on Technical Feasibility 



a. Capacity of the Communications System 

There is a generally accepted expectation that the data requirements of 
MTACCS will exceed the capability of current equipment. Clearly, enhancements are 
required to boost the capability of the communications equipment. Developing these 
enhancements will take time, but there are at least several reasons for optimism; 

1. The problem is already generally accepted. 

2. The Army does have a plan to develop packet switch appliques to enhance 
communications capability. 

3. MTACCS will be developed incrementally and is not expected to immediately 
overwhelm the communications system. 

b. Multi-level Security 

Although there is not a capability currently available, there has been a lot 
of promising progress in the commercial market place. At the rate of present 
development and market demand by the civilian sector, a multi-level security capability 
should be available within the next few phases of the MTACCS Field Development 
System. 

c. Software Development 

While software development continues to be an exceedingly difficult task 
throughout DOD, the initial outlook for MTACCS is favorable. MTACCS software 
development is still in its infancy, but the development procedures and criteria that have 
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been established are in complete agreement with software experts throughout both DOD 
and industry. If these procedures are maintained and adhered to, a successful software 
development project is likely. 

E. LEVEL OF COMPLEXITY ASSESSMENT 

It is explicitly stated in the MTACCS Operational Concept that: 

Systems and/or equipment complexity and operational sophistication shall be kept 
to a minimum consistent with providing the required operational capability to the 
MAGTF. [Ref. l:p B-1] 

While MTACCS is intrinsically complex, the current development approach does 
tend to limit the complexity of each FDS phase. A small, limited set of goals will be 
established for the first increment of MTACCS. Only those goals will be pursued. 
Greater sophistication will be left to foUow on increments. 

Throughout all of the FDS and MTACCS documents, there is a common theme: 
MTACCS must not and will not attempt to tackle too much in any one increment. There 
is caution expressed at every turn. The emphasis on the "build a little, test a little, field 
a little" approach is a reassuring indication that the project will proceed with complexity 
held within practical limits. 

F. ASSESSMENT OF ACQUISITION STRATEGY 

4 

1. The Impact of Acquisition Strategy 

Poor acquisition strategy decisions can have serious adverse effects on any 
program. In retrospect, it was a poor strategy of the MEFASS program, for example, to 
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choose hardware configurations first, then work on software. The negative effects of this 
strategy were pointed out in Chapter II. The use of an appropriate acquisition strategy 
is vital to the success of the program. 

2. Acquisition Strategy Defined 

Acquisition strategy is defined in the Defense Systems Management College 
Acquisition Strategy Guide as: 

A conceptual basis of the overall plan to follow in program execution. The 
acquisition strategy is the basis for all functional strategies, plans, and tasking; it 
provides a coordinated approach to achieving program objectives within the 
constraints placed on the program. [Ref. 53:p 3-21] 

The main ingredients for successful acquisition of systems involves strategic, 
technical, and resource concerns. Program objectives must be established, controlled, and 
assessed to permit the deployment of a militarily useful system that meets cost, schedule, 
performance, and supportability goals. 

The acquisition strategy must show how the system and program objectives 
will be met, how policy and procedures will be accommodated, and how the conduct of 
the program will meet such criteria as realism, stability, resource balance, flexibility, and 
controlled risk. [Ref. 53 :p 3-21] 

The benefits of a sound acquisition strategy allow the program manager to 
maintain control and provide direction to his management effort. Some of the realized 
benefits are: 

1. Providing a consistent and organized approach. 
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2. Providing a coordinated approach to achieving program objectives economically 
and effectively through informed and timely decisions. 

3. Providing a baseline for preparing plans and activities to facilitate program 
understanding and agreement. 

4. Documenting decisions and assumptions made in the process of acquisition. 

5. Providing important political credibility. [Ref. 53:p 3-2] 



These are more than just benefits, they are crucial to a systems success. 
Without them, political support, and hence financial support, is difficult to maintain. 

The acquisition strategy should be determined as early in the systems life cycle 
as possible. The impact of decisions made early in the cycle substantially determine the 
majority of the costs later in the cycle. 

[Ref. 53:p 3-2] 

3. The MTACCS Acquisition Strategy 
a. Evolutionary Acquisition 

The MTACCS acquisition concept is a "build a little, test a little, field 

a little" approach using off-the-shelf equipment and software where applicable. It is a 

strategy known as "Evolutionary Acquisition". Evolutionary Acquisition is defined as: 

An acquisition strategy which may be used to procure a system expected to evolve 
during development within an approved architectural framework to achieve an 
overall systems capability. An underlying factor in Evolutionary Acquisition is the 
need to field a well defined core capability quickly in response to a validated 
requirement, while planning through an incremental upgrade program to eventually 
enhance the system to provide the overall system capability. These increments are 
treated as individual acquisitions, with their scope and context being the result of 
both continuous feedback from developing and independent testing agencies and the 
user... [Ref. 54:p 23] 
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Requirements are to originate from the Fleet Marine Force to ensure users 
needs are met. System development must be managed from the Program Executive 
Officer (PEO) to ensure an integrated system. User requirements will be satisfied in 
a coordinated, evolutionary manner using non-developmental automation and 
secure/reliable digital communications equipment. [Ref. l:p 7] 

The MTACCS Operational Concept Document establishes the following 

policies: 

1. Marine Corps requirements for new acquisition shall be satisfied, whenever 
suitable and acceptable, through the programs of other services, government 
agencies, or joint developmental efforts. 

2. When existing, proven technology will satisfy a requirement, it shall be used. 
Standard Marine Corps equipment and other off-the-shelf components shall be 
used unless specific justification to do otherwise is provided. [Ref. 1: Appendix B] 

Again, these policies imply the maximum use of Non-Developmental Items (NDI) and 
Commercial Off-The-Shelf (COTS) material. 

Evolutionary acquisition is an alternative acquisition process used to acquire 
command and control systems that are expected to evolve during development and 
throughout their operational life. 

Figure 22 graphically represents the application of an evolutionary acquisition 
approach. The figure emphasizes that the initial preliminary system architecture is 
segregated into planned increments. Those increments are then refined, funded, and 
developed in stages. [Ref. 55] 
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Figure 22: A Model of Evolutionary Acquisition [Source: Ref. 55] 
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b. Motivation for Employing Evolutionary Acquisition 



The Marine Coqjs has chosen to develop MTACCS through the use of 
Evolutionary Acquisition for several reasons; 

(1) Lessons Learned From MIFASS. As discussed in Chapter II, the 
Marine Corps' attempt at the "big system approach" has failed miserably in the past at 
extreme cost. It was simply too hard to adjust requirements and specifications to keep 
up with both user demand and technology, and quickly incorporate these adjustments into 
a system. [Ref. 32:p 16] Using Evolutionary Acquisition, improvements or changes can 
be made at the next incremental upgrade and can be made easily if the original core 
design was built with changes in mind. 

(2) Lack of a Firm, Complete List of Defined Requirements. A complete 
list of C^ automation or support requirements would be impossible to generate. The 
introduction of new technology and procedures makes old tasks easier and opens the door 
to provide new capabilities. This makes it difficult to predict the final requirements. [Ref. 
32:p 16] By using Evolutionary Acquisition, the user can provide timely, accurate 
feedback of what he wants, needs, and actually uses. This feedback can be applied to the 
next increment and tested. 

(3) Growing Political Acceptance of Evolutionary Acquisition. The use 
of Evolutionary Acquisition as an alternative acquisition strategy is consistent with the 
guidance of 0MB Circular A- 109, DoD Directive 5000.1, and with Defense Acquisition 
Circular 76-43. Evolutionary Acquisition encourages regular and continual interaction 



112 



with Deputy Program Managers (DPM)^"*, requirements proponents, users, developers, 
testers, and logisticians. It encourages the consideration of Non-Developmental-Items 
(NDI) and Commercial-Off-the-Shelf (COTS) materiel where applicable. [Ref. 32;p 16] 
By this continual interaction, the risk of spending a large amount of resources with no 
measurable return is reduced. The program is reviewed by all concerned at each 
increment. Those responsible for certain fields will have to interact repeatedly with those 
responsible for the other fields that could effect them. 

(4 ) The Ability to Impact and Coordinate Subordinate Programs. Since 
several of the MTACCS component systems are being developed by separate DPMs under 
the PM, MAGTF C^, each DPM will be given the same set of standards, interface criteria, 
and requirements to incorporate into their systems. The DPMs will manage the 
development of their separate systems, but with a common goal to be achieved. Their 
progress will be reviewed for compatibility by the same senior; one person, not a 
revolving committee. [Ref. 32:p 17] This will help to ensure that MTACCS subsystems 
are interoperable and the Marine Corps will not suffer drastic logistical burdens 
supporting a multitude of completely different systems. 

(5) The User Response is Quickly Incorporated. By starting with 
equipment and procedures the user is already familiar with, and incorporating a limited 
amount of change at each increment, the user can easily assimilate and evaluate the 



^ Deputy Program Managers are responsible for subsystems under the MTACCS 
engineering effort. They report to the PM, MAGTF C^. 
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change, providing appropriate and accurate feedback. Through the use of FDS, this is 
possible. 

(6) Capabilities are Fielded Faster. Evolutionary Acquisition permits 
faster fielding of core capabilities to the user. It allows building on existing equipment 
and systems to quickly field a useful core capability and concurrently develop component 
systems, capitalizing on the ability to incorporate component systems as they complete 
their individual development phases. [Ref. 32:p 16] This permits new technology to reach 
the user at a rate that is much faster than currently possible. 

4. Assessment of the Feasibility of the Evolutionary Acquisition Strategy 

a. Emergence of Evolutionary Acquisition 

Evolutionary Acquisition is gaining recognition as a strategy that provides 
the flexibility necessary to adapt evolving command and control systems. Robert R. 
Everett has written; 

I believe that to resort to evolution is not a failure of the overall design process, but 
recognition that evolution is the way that complex systems actually do change. 
[Ref. 40] 

In 1987, the Joint Logistics Commanders^ endorsed a guide for 
evolutionary acquisition. The guide was prepared by the Defense Systems Management 
College. The guide noted: 



“ The Joint Logistics Commanders are the Commander, U.S. Army Materiel 
Command, the Deputy Chief of Naval Operations (Logistics), the Commander, Air Force 
Logistics Command, and the Commander, Air Force Systems Command. 
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Significant studies have been conducted in the field of evolutionary acquisition 
by authoritative, learned and experiences groups representative of public and private 
sectors of our economy. These studies have concluded that for the acquisition of 
systems an evolutionary approach should normally be used. [Ref. 55] 

Brigadier General Edward Hirsch^^ USA (Ret), wrote in an article in 
Signal magazine: 

Evolutionary Acquisition is not a cure-all for the real or perceived ills of the U.S. 
acquisition process; but it does hold some promise to help field command and 
control systems sooner, at lower cost and with higher user satisfaction than other 
approaches. [Ref. 54:p 23] 

b. Non-Developmental Items and Commercial-Off-The-Shelf Products 

Non-Developmental Items and Commercial-Off-the-Shelf products are 
generic terms that describe material available from a variety of sources with little or no 
development by the government. These are items that are either available in the 
commercial market place or from other services. 

According to William H. Taft IV^^, 'The use of Off-The-Shelf sources 
is a major initiative of the Department of Defense [Ref. 56; p 103]. There is 
considerable motivation for the Marine Corps to pursue this element of acquisition 
strategy wherever possible. Non-Developmental Items yield several benefits: 



1. The time in development and the time to fielding is greatly reduced. 

2. Users requirements and needs can be met and satisfied quickly. 



" Director, Center for Acquisition Management Policy, Defense Systems 
Management College at the time of publication of the article. 

Former Deputy Seaetary of Defense. 
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3. Costs for Research and Development are reduced. 

4. Current, state of the art technology is used and fielded. [Ref. 57] 

However, there are risks involved with using Non-developmental Items. 

These include: 

1 . Cost and performance tradeoffs to accommodate the use of NDI components in 
production. 

2. The resulting proliferation of hardware and software can cause logistic support, 
training, and configuration management problems and possible increased life cycle 
costs. 

3. Safety deficiencies may occur because the NDI was not built specifically for a 
military environment. [Ref. 57] 



The benefits of using NDI should aid in the fielding of MTACCS 
tremendously. The risks are being minimized through the use of the common hardware 
and common software. By restricting the amount and type of each, many of the logistical 
and training burdens are alleviated. 

c. Conclusions on Acquisition Strategy 

The Evolutionary Acquisition strategy is widely accepted as an 
appropriate method for developing complex, integrated systems. William E. Leigh and 
Clifford Burgess^* assert in their book Distributed Intelligence : 

Building complex, integrated systems in a single project seldom is successful and 
rarely is attempted. Normally, integrated systems are the result of an evolutionary 



Associate Professors, University of Southern Mississippi when they published 
their book in 1987. 
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sequence of development, modification, and enhancements of multiple systems 
originally designed to operate in a stand alone fashion. [Ref. 39: p 50] 

... attempting to solve a problem or set of problems that is too large in scope 
virtually guarantees that the solution will be obsolete by the time it is developed 
fully. [Ref. 39: p 56] 

... options that can be implemented as modules that are relatively narrow in scope 
are becoming increasingly attractive. [Ref. 39:p 56] 

The use of this strategy in the development and procurement of MTACCS 

dramatically increases the probability of success, but it is still not tested on a project of 

such complexity. 

G. CONCLUSIONS ON FEASIBILITY 

The MTACCS concept is feasible. The use of an Evolutionary Acquisition strategy 
markedly strengthens the program. In an evolutionary , incremental development, 
advances in technology can be more readily introduced as upgrades to the core system. 
There are several factors, however, that can undermine the basic feasibility of the project. 
These factors must be addressed and mitigated to ensure they do not inhibit development. 

1. Use of Data Communications 

The MTACCS program must ensure that informal communications and voice 
radio are not entirely supplanted by data communications. To rely too heavily on data 
transmissions violates the spirit of Marine Corps doctrine and runs the risk, as Van 
Creveld said, of "reducing command to trivia" [Ref. 41:p 273]. 
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2. Centralization 



A clear vision of the degree of centralization of command and control must 
be established early and maintained. In addition, it is vital that the degree of 
centralization be strongly supported across the entire Marine Corps. There must be 
consensus. Division on this highly critical issue can cripple the program. 

3. Communications Capacity 

The simultaneous development of both MTACCS and its supporting 
communications system is a hauntingly familiar scenario. The MIFASS system was also 
intended to operate with communications equipment that was being developed 
concurrently. When the communications equipment experienced delays, MIFASS was 
handicapped. It did not have a communications system capable of providing adequate 
support. The Marine Corps must be very concerned that this does not occur again with 
the "revitalized" MTACCS. The Naval Research Advisory Committee has cast doubts 
on the ability of both current and future communications equipment to handle the load. 
Action must be taken to plan for that contingency. 

4. Multi-level Security 

Continued emphasis must be placed on establishing multi-level security if TCO 
is to interface with IAS and provide unit commanders with real time intelligence. 
Without a demonstrated secure, trusted system, there will be little user support for 
allowing classified information of a sensitive nature to be passed on MTACCS nets. 
There is a need to allow users of differing security levels to be able to access the same 



118 



system using the same database. Until this can be done with a high degree of confidence, 
our intelligence system could be unintentionally violated. Fortunately, there appears to 
be a strong interest displayed, by both industry and the services, in the development of 
multi-level security for both military and commercial applications. It appears that the 
Marine Corps need only follow those developments closely and evaluate candidate 
methods to determine the method most appropriate for Marine Corps needs. 

5. Software Development 

Software development continues to be DOD's "Achilles' heel". The MTACCS 
development team has laid out a development plan that incorporates the best advice of 
the time. However, the plan must be adhered to. The software must be adequately tested 
and progress demonstrated to avoid making decisions based on promises and reputations 
as MIFASS did. The acquisition strategy must be able to react to new technologies, 
processes, and strategies. 
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V. COST-EFFECTIVENESS ASSESSMENT 



A. INTRODUCTION 

1. Purpose of this Chapter 

The purpose of this chapter is to examine the combat effectiveness of 
MTACCS in relation to its cost. Automation of a particular task or set of procedures is 
generally thought to improve combat effectiveness. While MTACCS may indeed improve 
the efficiency with which assets are used and increase the overall effectiveness of the 
Marine Corps, is it the most cost effective method? Could the same level of effectiveness 
be achieved at a lower expenditure of resources if something else was purchased? These 
questions will be addressed here. 

2. The Importance of a Cost-Effectiveness Assessment 

The procurement of a C^ system as extensive as MTACCS is an expensive 
proposition. Hundreds of millions of dollars were spent on the failed MIFASS system 
alone. Given this significant investment, several vitally important issues must be 
addressed: 

1. Is it worth the expense? 

2. Will it significantly enhance combat effectiveness? 

3. Would the Marine Corps be better off to buy more weapons and less C^? 

4. What is the most cost-effective level of automation? 
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These are difficult questions to answer. The information presented here 
provides insight to possible answers, but does not address the level of detail necessary to 
determine the best answers. 

3. Assessment Methodology 

Questions of this nature are generally answered by cost-effectiveness studies. 
A complete cost-effectiveness study of MTACCS as it currently stands, is beyond the 
scope of this thesis. Fortunately, several cost-effectiveness studies have been completed. 
Two of these studies will serve as a foundation for an assessment of the potential of the 
"revitalized" MTACCS to enhance combat effectiveness. Both were conducted in 1981 
by the Center for Naval Analyses (CNA). The first is a study of the Tactical Combat 
Operations (TCO) system as it stood then. The second addresses the Marine Air Ground 
Intelligence System (MAGIS). 

Cost-effectiveness may be assessed in two parts: combat effectiveness and 
cost-effectiveness. First, the combat effectiveness section will examine the change in 
combat capability that MTACCS may provide. The cost-effectiveness section then relates 
the amount of change in combat effectiveness that can be attributed to MTACCS to the 
resource cost of the system. 

This chapter will use TCO as its primary example due to the role TCO will 
maintain as the system integrator for MTACCS. It is, in essence, the hub of MTACCS. 
TCO possesses the functions and tools with which to allocate forces and assets, while 
processing intelligence, and disseminating orders and plans. TCO is the primary 
component of the initial MTACCS development. It is geared towards providing 
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automated assistance for MAGTF command and control through the integration of the 
MTACCS component systems. An assessment of TCO will closely approximate an 
assessment of the integrated MTACCS system. 

Additionally, a .second CNA study that addresses the Marine Air Ground 
Intelligence System (MAGIS) Intelligence Analysis Center (lAC) is reviewed. The lAC 
study has two drawbacks, however. First, only measures of performance were tabulated. 
Measures of force effectiveness were not considered. Second, a cost-effectiveness trade- 
off between the manual system and the lAC was not developed. 

4. Limitations of the Assessment 

The CNA studies were completed ten years ago, well before the 
"revitalization" of MTACCS. This places limits on the validity of an assessment of the 
"new" MTACCS. Extensive similarities remain, however, and much of the analysis of 
the earlier version of these can be applied today. The cost-effectiveness studies are used 
to illustrate the potential benefits and limitations of an automated C^ system. 

B. THE IMPACT OF MTACCS ON COMBAT EFFECTIVENESS 

An evaluation of combat effectiveness usually requires extensive modeling and 
simulation. Modeling and simulation, however, are outside the scope of this assessment. 
The impact of MTACCS on combat effectiveness will be concluded from prior studies. 
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1. The Center for Naval Analyses TCO Assessment 



a. Background 

The basic approach used in the TCO analysis was a three tiered approach. 
Each alternative was evaluated on a first level using measures of performance (MOP's), 
on a second level using measures of effectiveness (MOE’s), and on a third level using 
measures of force effectiveness (MOFE’s). The study concluded with the evaluation of 
the effectiveness of equal-cost alternatives. [Ref. 58:p 1] Five relevant 

alternatives were analyzed, four variations of TCO^^ and a manual system: 

1. Full TCO - TCO as described in Chapter III with fully functioning nodes down 
to the battalion/squadron level. 

2. Nodallv Austere TCO - The nodes at the battalion/squadron level were eliminated. 

3. Functionally Austere TCO - Decision aids were eliminated at all levels. 

4. Very Austere TCO - The nodes at the battalion/squadron level were eliminated 
and the decision aids at all levels were eliminated. 

5. Manual System - The majority of information was maintained on status boards, 
oyerlays, and paper files. 



The CNA analysis eyaluated TCO with the MIFASS concept before the 
revitalization of MTACCS in 1989. Since the majority of the MTACCS subsystems were 
in the development phase, only the concepts and not the systems themselves were being 
analyzed. The concept for TCO has remained essentially the same in many respects. 
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b. Evaluation Criteria 



(1) Measures of Performance 

(a) Timeliness. Timeliness represents the time that elapses between 
the first occurrence of an event and when information concerning that event is processed 
and translated into action. 

(b) Accuracy. Accuracy is the degree of correctness of the 
information in the system. Each system can only be as accurate as the information put 
into it. [Ref. 58:p 7] It is assumed that the same caliber of input is used in each case, and 
the measurement of accuracy is in the transmission of the data.^° 

(c) Decision Aids. The change in effectiveness due to decision aids 
was measured through the use of three decision aids: Battlefield Simulation, Air Routing, 
and Air Weaponeering. Battlefield Simulation is basically a war game with which to test 
and improve operational plans before implementation. Air Routing allows the pilot to 
choose the optimal route with an Electronics Counter Measures (ECM) plan to ensure 
survival and mission effectiveness. Air Weaponeering aids in matching targets with 
optimal weapons.’’ [Ref. 58:p 6] 



In a manual system, information can be significantly delayed resulting in 
erroneous perceptions. These delays are usually due to voice transmission taking too long 
to convey information and having to wait for a turn on the net. In an automated system, 
messages generally travel faster with greater accuracy, 

” The current TCO system has not yet identified the decision aids to be included. 
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(2) Measures of Effectiveness 

(a) Perceptions. The commander’s estimate of enemy strength was 
used as an indication of his perception of the battlefield. [Ref. 58;p 6] 

(b) Resource Allocation. The allocation of rifle squads between 
front line battalions and the reserves was used as an indication of resource allocation. 
The more accurate the commander’s perception of the battlefield, the more accurately he 
can allocate his forces. [Ref. 58:p 6] 

(3) Measure of Force Effectiveness. The loss ratio was used as a 
measure of force effectiveness. The loss ratio was defined as the ratio of enemy losses 
to friendly losses after two days of simulated battle. [Ref. 58:p 6] 

c. Effectiveness Results 

(1) Time Delay (Figure 23). There is a readily observable difference 
between the automated systems and the manual system. This was attributed to increased 
processing speed and transmission speed. The human processing at the receiver is 
considered the same for each system. It became apparent that decision aids are not a 
factor in the speed of the decision based on these results. [Ref. 58:p 4] 

(2) Error Rates (Figure 23). Again, there appears to be a significant 
difference between automated and manual systems. Automated systems demonstrate half 
the error rate of the manual system. 
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Time Delays 



Error Rates 





Figure 23: Error Rates and Time Delay [Source: Ref. 58] 



(3) Decision Aids. In the analysis. Battlefield Simulation yielded a 26% 
decrease in the rate of friendly casualties. Air Routing produced a 30% reduction in 
aircraft vulnerability. Air Weaponeering increased the effectiveness of delivered ordnance 
by 76%. [Ref. 58:p 5] Qearly, decision aids can contribute greatly to the combat 
effectiveness of a force. 

(4) Perceptions (Figure 24). The study also analyzed how the 
improvements in a system can impact the commander’s perception of the battlefield. 
The starting premise was: 

The current perception is a function of the previous perception and the "new" 
information that is becoming available. Due to time delays in the system, the 
"new" information may be hours old. These two factors are weighted so that the 
higher the confidence in the "new" information, the more reliance on it. 
[Ref. 58:p 6] 
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MANUAL 



FULLTCO 





Figure 24: Perceptions of Enemy Strength in the TCO assessment [Source: Ref. 
58] 

It became obvious from the results and from military experience, that 
perceptions will tend to lag behind the actions and intentions of the enemy. Figure 24 
depicts this time lag of friendly perceptions and enemy actions. The analysis 
demonstrated that the automated system had roughly a one hour time lag while the 
manual system averaged a four hour time lag. There was also a noticeable difference in 
the accuracy of the commander’s perception. Accuracy in enemy strength showed an 
average error of 1300 soldiers for the manual system. The average error was only 350 
soldiers for the automated system. Overall, the automated system resulted in a much 
more accurate perception of the battlefield. 
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(5) Resource Allocation. Resources were allocated based on perceptions. 
Figure 25 shows the movements of rifle squads between the front lines and the reserves. 
The allocation of rifle squads was based on a fixed decision rule which was a function 
of the current battlefield perceptions. Therefore, the more accurate the perception of 
enemy forces and intent, the more appropriate and effective the allocation. The manual 
system, due to its inaccuracies in perception, assigned rifle squads in a poor fashion as 
compared to the more accurate TCO system. [Ref. 58;p 6] 




Figure 25: Resource Allocation in the TCO assessment [Source: Ref. 58] 

(6) Loss Ratio. In the analysis^^, battle outcome was determined by 
the final loss ratio. The results were all normalized and portrayed relative to friendly 
losses. Command and control was incorporated by keeping track of the two views of the 



The analysis used a deterministic, two sided computer model know as the C^ 
Model. The model portrays a large scale amphibious assault of a Marine Expeditionary 
Force. 
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battlefield; the commander’s perception and the actual situation. Plans, resource 
allocation, and control of the battle were conducted based on the commander’s 
perceptions. The outcomes of the commander’s decisions, of course, were based on the 
actual situation. Table I shows the resulting final loss ratios. [Ref. 58:p 8] The ratios can 
be roughly segregated into three levels of effectiveness. The Full TCO and Nodally 
Austere TCO achieved a similar level of effectiveness, performing significantly better than 
all of the other systems. The Functionally Austere TCO and Very Austere TCO both 
performed at a similar level of effectiveness that was significantly lower than the other 
two automated alternatives. The overriding difference between these two and the other 
automated systems is in the use of decision aids. The values shown in Table I illustrate 
the relatively higher value of decision aids compared to that of having additional 
automation at lower echelons. Again, this implies that decision aids can significantly 
impact the outcome of the battle. 

2. The Center for Naval Analyses MAGIS Assessment 
a. Background 

The CNA analysis focused on a cost and operational analysis assessment 
of the MAGIS Intelligence Analysis Center (lAC). Three automated alternatives to the 
lAC were considered, but none were found to be suitable. These were the existing 
intelligence systems of the Army, Navy, and the Air Force. The study, then, compared 
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Table I: LOSS RATIOS IN THE TCO ASSESSMENT 
[Source: Ref. 58] 



RELATIVE 

ALTERNATIVE LOSS RATIO 



FULL TCO 1.14 

NODALLY AUSTRER TCO 1 . H 

FUNCTIONALLY AU JTERE TCO 1 . 04 

VERY AUSTERE TCO 1.03 

manual 1 . 00 



only two alternatives: the lAC and a manual system. The effectiveness data came from 
two sources. The 1975 operability test of the Intelligence Analysis Storage and Retrieval 
System was the source for manual data. The 1979 Developmental Test II of the I AC 
provided data for the automated alternative. [Ref. 46:p v] 

b. Methodology 

In the previous TCO analysis, a three tiered approach was used. The 
TCO system was evaluated against measures of performance (MOP), measures of 
effectiveness (MOE), and lastly, measures of force effectiveness (MOFE’s). In the lAC 
analysis, only performance was measured. [Ref. 59] 
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c. Measures of Performance 



here. 



The measures of performance used during the lAC analysis are defined 



(} ) Percentage of Required Products Produced. The number of required 
products that are actually produced by the test team divided by the total number required. 
[Ref. 59:p 33] 

(2) Completeness. The percentage of items that are complete, based on 
those outputs that are actually produced. The percentage is obtained by comparing the 
items completed by the test team with the predetermined solution. [Ref. 59:p 33] 

(3) Accuracy. The percentage of those items completed that are correct, 
based on the predetermined solutions. [Ref. 59:p 33] 

(4) Timeliness. The deviation between the actual output time and the 
scheduled output time. A negative timeliness score indicates that the output was produced 
earlier than required. [Ref. 59;p 34] 

d. Summary of Effectiveness Results in the lAC Analysis 

The CNA study concluded that the lAC was a significant improvement 
over the manual system. Test results showed that the lAC provided a marked measure 
of improvement in the first three of the performance measures. The measure of 
timeliness, however, greatly favored the manual system. For this reason, the analysts 
expressed concern that the results of the two tests were not entirely comparable in the 
timeliness measure. Some limitations were developed as a result of these conclusions. 
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e. Limitations of the CNA MAGIS Assessment 



(1) mop’s versus MOFE’s. Measures of performance (MOP’s) are an 
indicator of the isolated performance of the system only. MOP’s do not provide an 
accurate indication of the overall impact on combat effectiveness. [Ref. 59] 

(2 ) Two Tests not Entirely Compatible. As mentioned earlier, the results 
of the two tests were compiled to produce the MAGIS lAC assessment. These tests were 
not administered under the same, or in some cases, even similar conditions. CNA 
analysts were required to manipulate the test data to achieve a rough comparability 
between the tests. [Ref. 59] 

(3) Production of Required Reports. In the manual method, production 
of required reports could begin at any time. Intelligence personnel were able to start 
reports well before the required delivery time based on information available at the time. 
Users of the automated system were not permitted to begin report preparation until a 
certain time prior to the required delivery time. [Ref. 59] 

/. Conclusions on the Effectiveness of the I AC 

The CNA analysis revealed that automation of the intelligence system has 
the potential to substantially improve system performance. The analysis has limited 
utility, however, because it did not address the potential of the automated system to 
improve force effectiveness. 
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C. COST-EFFECTIVENESS 



1. Definition 

Cost-effectiveness studies generally attempt to evaluate the effectiveness of 
various alternatives on a common scale, then relate the effectiveness "score" for that 
system to its cost. A system is most cost-effective when it provides a larger incremental 
increase in effectiveness per unit of cost. 

2. The TCO Cost-Effectiveness Assessment 

a. Background 

The TCO study performed an equal cost analysis with the five systems 
described earlier. The most expensive system, full TCO, was used as a cost baseline. 
The difference in cost between the Full TCO alternative and the other systems was used 
to purchase more firepower. Additional tanks were added to the less expensive 
alternatives. Figure 26 shows the breakdown of the estimated costs of the C^ systems 
plus the number of tanks added to achieve equal cost forces. Using the C^ model 
described earlier, the equal cost forces were evaluated and the final loss ratios tabulated. 
[Ref. 58:p 10] 

b. Cost-effectiveness Results 

The cost-effectiveness results in Table II show that automation of 
command and control is an effective method of increasing combat effectiveness. It is 
important to point out, however, that the Full TCO was not the best performer. The 
Nodally Austere TCO system did achieve a higher score in loss ratio. Although the 



133 




difference may not be statistically significant, the implication is clear. Given the ability 
to buy firepower, or C^, or a combination of both, choosing a proper combination may 
be the most appropriate decision. 

c. Limitations of the TCO Study 

The results of the TCO study must be tempered with the facts that: 

1. Only tanks were used as additional sources of firepower. If the money had been 
spent on helicopters, artillery, or additional forces the outcome of the simulation 
could have been different. 

2. It was a specific scenario against a specific enemy. 

3. Only one type of computer model was used. 
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Table II: EQUAL COST LOSS RATIOS [Source: Ref. 
58] 


ALTERNATIVE 


LOSS RATIO 


NODALLY AUSTERE 


1.14 


TfO , - - - 


1.13 


VERY AUSTERE TCO 


1.03 


FUNCTIONALLY AUSTERE TCO 


1.01 


manual 


1.00 



4. The computer model is only a representation of reality; a representation of 
unknown fidelity. 

d. Summary 

The Center for Naval Analyses study of the TCO system showed that the 
automation of command and control tasks can greatly increase combat effectiveness. It 
is also important to note from the results, that automation of below the regimental 
level did little to enhance the overall force effectiveness results. The study does have 
limitations, however, particularly in the use of additional tanks to increase fire power. 
The current trend in the Marine Corps is towards a "lighter" force. The addition of more 
tanks is an unlikely possibility. 
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D. CONCLUSIONS 



The "revitalized" MTACCS concept intends to establish "work station equipped 
nodes at every echelon throughout the MAGTF" (underline added) [Ref. l:p 7]. The 
MTACCS Master Acquisition Plan provides a communications architecture diagram that 
implies automation will be provided down to the battalion level at the very least 
[Ref. 32:p 6-8]. 

Based on the results of the TCO study, automation of this degree may not be the 
most cost-effective method of increasing combat effectiveness. The study showed that 
the Austere TCO performed basically as well as Full TCO. This can lead to the 
conclusion that the automation of the lower levels is not as effective or not feasible. 
There may, however, be cause to doubt the applicability of these results to the TCO 
study. The apparent lack of benefit from full TCO may have been a result of a portability 
problem that no longer exists. Ten years ago, the capability of portable equipment was 
minuscule compared with current capabilities. Generally a large heavy piece of 
equipment was necessaiy to achieve any significant level of processing capability. TCO 
was intended to use the same equipment as MIFASS. Recall form Chapter II that the 
MIFASS equipment was universally recognized as too heavy. The TCO of ten years ago 
may have overwhelmingly encumbered the lower echelons. The majority of the lower 
command levels are active participants in "Maneuver Warfare". They shoot and move and 
stay on the go. Modem data processing and telecommunications technologies, however, 
have the potential of providing sufficient automation to the lower command levels in a 
much smaller, much lighter package. These are important issues that should be examined 
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before such an analysis is used as a justification for a particular degree of automated 
command and control. 

The most significant conclusions to be drawn from this chapter are these: 



1. Automation of command and control functions has the potential to significantly 
enhance the combat effectiveness of the Marine Corps. 

2. The proper level of automation may not be "all you can get". The most cost 
effective level of automation may be that which restricts automation to the higher 
headquarters; regiments and above. 

3. The rapid pace of technological progress in data processing and 
telecommunications calls into question the applicability of the CNA studies to the 
TCO and MAGIS systems of today. [Ref 58:p 11] 
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VI. COMBAT DEVELOPMENT ASSESSMENT 



A. INTRODUCTION 

1. Dennition of Combat Development 

The Marine Corps recognizes that it must continually evaluate its own combat 
effectiveness and efficiency, and develop guidance and direction that plans the course of 
the Marine Corps in the years ahead. Planning that course and guiding the Marine Corps 
along the way, is called combat development. The responsibility for combat development 
is primarily vested in the aptly named Marine Corps Combat Development Command 
(MCCDC). There does not appear to be a formal definition of combat development. For 
the purposes of this assessment, combat development is defined as the evaluation of 
current combat capabilities and effectiveness and the subsequent planning and 
implementation of a development effort designed to meet anticipated requirements. 
Mainly, combat development consists of: 

1. Development of concepts, plans, and doctrine. 

2. Threat assessment 

3. Development of training requirements. 

4. Identification of requirements for changes to doctrine, training requirements, force 
structure, and equipment. 

5. Development of required operational capabilities. 

6. Mission Area Analysis. [Ref. 26:p 3-21] 
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The goal of combat development is to ensure that the Marine Air Ground Task 
Force of the future will be capable of effectively accomplishing its assigned missions on 
the battlefields of the future. 

2. The Impact of Combat Development on MTACCS 

The MTACCS program is a direct result of combat development efforts in the 
Marine Corps. It was through combat development that the need for MTACCS was 
determined. Combat development will continue to chart the course of MTACCS 
throughout its operational life. 

3. Objective 

The objective of this chapter is to assess the combat development practices 
used within the Marine Corps that directly impact the MTACCS program. These 
practices will play a major role in shaping the evolution of MTACCS, and to a large 
degree, will determine its fate. 

4. Lack of Contractor Information 

The systems engineering practices used by contractors will also impact combat 
development in general and MTACCS in particular. Pacific Northwest Laboratories 
(PNL) is the system engineer and integrator for MTACCS. They have not yet formally 
published their Systems Engineering Management Plan (SEMP) and a draft could not be 
attained. Many other contractors including Command Systems Incorporated (CSI) and 
Atlantic Research Corporation (ARC) are working on various segments of MTACCS. 
While their methods would be necessarily similar, each undoubtably has their own 
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individual approach to systems engineering. For these reasons, the systems engineering 
methodology employed by contractors is considered beyond the scope of this thesis and 
will not be assessed. 

5. Assessment Methodology 

Combat Development practices in the Marine Corps are similar to a systems 
engineering methodology. The objective of both, in the simplest sense, is to develop a 
"system" that can effectively accomplish its assigned tasks. An assessment of combat 
development, therefore, can be accomplished through a comparison with established 
systems engineering techniques. The methodology for assessment, then, consists of the 
following steps: 

1. Describe current Marine Corps combat development practices. 

2. Describe the impact of these practices on MTACCS. 

3. Define systems engineering. 

4. Develop a system view of the Marine Corps. 

5. Identify the impact of applying systems engineering to combat development in the 
Marine Corps. 

6. Outline of this Chapter 

Section B of this chapter describes in general terms how combat development 
is currently accomplished in the Marine Corps. Section C describes the impact of combat 
development practices on MTACCS. In Section D of this chapter, systems engineering 
is defined and explained. This definition provides the basis for a comparison with combat 
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development. Systems engineering models are developed to establish a baseline process 



for effective systems engineering. The models represent an ideal systems engineering 
effort; everything done correctly. Section E develops a system view of the Marine Corps. 
In section F, the possible impact of applying a systems engineering methodology to 
combat development is described. 

B. COMBAT DEVELOPMENT IN THE MARINE CORPS 

1. The Combat Development Team 

The combat development team in the Marine Corps is primarily compo.sed of 
three organizations: MCCDC, MCRDAC, HQMC. Figure 27 outlines the 

interrelationships between these activities. The functions and responsibilities of these 
organizations were described in Chapter III. 

a. Marine Corps Combat Development Command (MCCDC) 

The Marine Corps Combat Development Command (MCCDC) is ta.sked 
with analyzing current and anticipated Marine Corps missions and developing concepts, 
plans, doctrine, force structure, and equipment requirements to support those missions. 

b. Marine Corps Research, Acquisition, and Development Command 
The Marine Corps Research, Acquisition, and Development Command, 

as its name implies, is primarily tasked with managing the research, acquisition, and 
development of new equipment to meet the needs of the Marine Corps. MCRDAC, then, 
provides feedback to the Combat Development Command on technological capabilities. 
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Figure 27: MCCDC, MCRDAC, HQMC Interrelationships [Source: MCCDC] 
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c. Headquarters Marine Corps 

Headquarters, Marine Corps sets policy and must approve combat 
development recommendations. 

2. Procedures 

Figure 28 provides a brief overview of the combat development cycle. The 
combat development procedures outlined here are a simplistic, high level representation. 
Details of activities occurring within the organizations have not been presented. 
Additionally, a considerable amount of operations analysis is accomplished by activities 
external to the Marine Corps such as the Center for Naval Analyses. 

a. Mission Area Analyses 

In many cases, the combat development process is initiated by a Mission 
Area Analysis. This analysis of a particular mission area, such as intelligence or 
command and control, identifies deficiencies and proposes recommended actions for 
correction. The combat development process then analyzes and evaluates the 
recommended solutions. Figure 29 gives a brief description of the process from a 
Mission Area Analysis to achievement of mission capability. 

C. THE IMPACT OF COMBAT DEVELOPMENT ON MTACCS 

Combat development is a complex process. The description of combat development 
presented in the previous section only scratches the surface of a very deep subject. For 
this reason, the impact of combat development on MTACCS is not entirely clear. There 
appears to be two trends, however, in the recommendations and decisions that result from 
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Figure 28: The Combat Development Process [Source: Authors] 
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Figure 29: Mission Area Analysis to Mission Capability [Source: Ref. 26] 



145 



the combat development process. From these trends, it is possible to generalize on the 
probable impact of combat development on MTACCS. 

1. General Trends 

Mission Area Analyses are key contributors to the combat development 
process. The recommendations that result from Mission Area Analyses, and subsequently 
from the combat development process, appear to follow two general trends. These trends 
will likely have an impact on the development of MTACCS. 

a. An Equipment Orientation 

The majority of recommendations appear to be equipment oriented; 
relating to improvement of existing equipment or the acquisition of new material or 
equipment. An examination of two recently completed Mission Area Analyses revealed 
that recommendations for materiel changes were most common. In an analysis of fire 
support deficiencies, materiel recommendations were offered as the solution to 15 of the 
29 noted deficiencies. [Ref. 60] Another Mission Area Analysis for assault 
support recommended materiel changes as at least part of their proposed solutions to 22 
out of 28 priority deficiencies. [Ref. 61] 

The possibility of an equipment or materiel orientation is not surprising. 
The requirement for Mission Area Analyses has its roots in the Office of Manpower and 
Budget (0MB) Circular A-109 which requires any major new system acquisition be 
preceded by an analysis of the mission. [Ref. 62] Mission Area Analyses were 
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intended from the very beginning to provide evidence to support the acquisition of new 
equipment. 

The development of MTACCS will also emphasize materiel and 
equipment solutions. MTACCS will not change the organization or structure of the 
MAGTF. Only procedures will be modified to some extent as tasks are automated. 
[Ref. 32] 

b. Basic Recommendations 

A second trend appears to be that the recommendations that result from 
the combat development process are only basic recommendations that do not offer 
integrated solutions. A basic recommendation may only address one element of the entire 
system, whereas an integrated recommendation might address a requirement for changes 
in several elements of the system. A "basic" recommendation for a communications 
deficiency, for example, might be to buy another radio. An "integrated" recommendation 
might be to adjust procedures to cut down on traffic requirements, reorganize the unit to 
allow for alternate communications paths, and reallocate traffic to alternative systems. 
The basic recommendation may be the best solution at times, but probably not all the 
time. The recommendations in Mission Area Analyses are rarely, if ever, as involved as 
the example of an "integrated" recommendation shown here. 

The process shown earlier in Figure 29 also fosters a basic approach to 
solutions. While the process diagram is necessarily simplified, it implies that solutions 
to a deficiency can be categorized as either training, doctrine, and force structure 
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recommendations or equipment recommendations. The diagram does not foster the idea 



of integrated solutions. 

In some sense, MTACCS is a basic recommendation as well. While the 
integration of component systems will be enormously complex, the underlying concept 
is relatively basic: automate tasks that are currently being done by manual systems, and 
allow those automated systems to share information. No attempt will be made, at least 
initially, to modify force structure or doctrine in concert with materiel procurement. 

2. Command and Control System Trends 

The development of command and control systems within DOD in general also 
appears to follow certain trends that are described here. 

a. Use of an "Applique Approach" for 

It appears to be a general trend in the military to acquire weapons systems 
first and then devise the command, control, and communications as an accessory 
[Ref. 63:p 5]. This method of development has been referred to as an "applique 
approach" [Ref. 64:p 17]. This approach can be sufficiently effective when the 
complexity of the system is relatively low. Command and control of what essentially 
amounts to the entire Marine Corps, however, is not low on the complexity scale. 

The Strategic Defense Initiative (SDI) is one example of a highly complex 
system with software challenges of unprecedented magnitude. In addressing the command 
and control of SDI, one report stated: 

The trade-offs necessary to make the software task tractable are in the system 
architecture. ..the "applique approach" of designing the system first and then writing 
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the software to control it is the wrong approach for SDI. System architecture and 
battle management must be developed together. [Ref. 63;p v] 

The MTACCS program appears to follow an applique approach as well. 
The MAGTF structure, doctrine, and communications have been set and MTACCS 
hardware and software will be applied as an accessory. As with SDI, the trade-offs 
necessary to make software development more manageable might be found in 
modifications to force structure, doctrine, or the communications architecture. It appears, 
however, that these elements of the Marine Corps system will not budge. 

b. Standardization is More Important than Optimization 

In the age of a seemingly boundless integration of transistors onto a single 

chip, merely coping with technology is consuming a majority of our efforts. Many in the 

military have virtually abandoned the idea of optimizing and are now simply trying to get 

their systems to work. Lieutenant Colonel C. Kenneth Allard, USAF, emphasized this 

point in his book Command. Control, and the Common Defense : 

The dominant issue in establishing a telecommunications path is not its optimization 
but standardization of the process. More important than doing things the best way 
is doing them the same way. [Ref. 30:p 17] 

MTACCS, too, may suffer from this plight. The challenge of "just 
getting it to work" is enormous. The complexity and volume of interfaces is so large, that 
the first priority appears to be establishing a demonstration model to field a limited 
capability. Optimizing appears to be a lesser concern. 
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D. A DESCRIPTION OF SYSTEMS ENGINEERING 



1. Introduction 

Combat Development has much in common with systems engineering. This 
section develops a description of systems engineering to serve as a framework for 
comparison. 

2. Deflnition 

A system is defined as a collection of elements organized to perform a set of 
designated functions in order to achieve a specific result. The elements which comprise 
a system include personnel, material, equipment, facilities, procedures, and information. 
The approach used to plan and design a system in its entirety is called systems 
engineering. The goal of systems engineering is to plan and design a system as an entity 
in order to satisfy the needs of the user. [Ref. 65] Effective systems engineering 
makes the successful operation of all subparts guarantee that the assemblage will perform 
the tasks for which it was intended. Many systems fail to accomplish what was expected 
due to inadequate, biased, or misleading communications between the system designers 
and the users. [Ref. 22:p 3] 

There are many definitions of systems engineering. The terms "systems 
engineering" and "systems engineering management" are often used interchangeably and 
the difference between them is occasionally blurred. Systems engineering can be defined 
as the application of scientific and engineering efforts to: 
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1. Transform an operational need into a description of system parameters and a 
system configuration through the iterative process of definition, synthesis, analysis, 
design, test, and evaluation. 

2. Integrate related technical parameters and assure compatibility of all physical, 
functional, and program interfaces in a manner which optimizes the total system 
definition and design. 

3. Integrate reliability, maintainability, safety, survivability, human and other such 
factors into the total engineering effort to meet cost, schedule, and technical 
performance objectives. [Ref. 66] 

The Defense Systems Management College concentrates on management 
aspects and defines systems engineering as the management function that controls the 
total system development effort for the purpose of achieving an optimum balance ^ all 
system elements. It is a process which transforms an identified operational need into a 
description of system parameters and integrates those parameters to optimize the overall 
system effectiveness. [Ref. 67:p 1-2] 

For the purposes of this thesis, systems engineering is composed of two 
elements, the engineering process and the management of the overall engineering effort. 
The systems engineering process consists of the steps and procedures used to define, 
design, and develop the system. Systems engineering management consists of the 
activities and decisions that control the process of the engineering effort. The systems 
engineering process is described in detail in the following sections. It is this description 
that will serve as a basis for comparison with combat development. 
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3. The Systems Engineering Process 



a. Definition of the Systems Engineering Process 

The systems engineering process is oriented toward system analysis, 
design, and definition. A sequential process is depicted in Figure 30. [Ref. 65:p 43] This 
figure represents the model that will be used in the systems engineering assessment. The 
process is defined in terms of tasks to be performed somewhat sequentially. 

b. A Systems Engineering Process Model 

The systems engineering process model consists of the steps depicted in 
Figure 30. Each step has several functions to be accomplished before the next step can 
be completed. 

(1) Requirements Analysis. A major problem with many systems is that 
the reasons to build the system do not necessarily fill operational requirements. The 
requirements analysis examines the current threat and mission needs. Once the needs 
have been validated to meet the threat, system performance requirements are defined. 
Utility functions are created to provide a method (a value system) to compare disparate 
characteristics of different systems on a relatively equal basis. The choice of the system 
to pursue is decided on the basis of a weighted decision matrix. Characteristics are 
evaluated and weighted and each system’s characteristics are measured. The alternatives 
with the highest scores are considered for further development. This is the key step of 
the system engineering process: translating mission requirements into system performance 
and design requirements. [Ref 65] 
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Figure 30: Systems Engineering Process [Source: Ref. 65] 
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(2) Functional Analysis. Functional analysis is a method for analyzing 
performance requirements and dividing them into discrete tasks or activities. It involves 
the identification and decomposition of the primary system functions into subfunctions 
at ever increasing levels of detail to establish a baseline of the functions that must be 
performed in order to satisfy system requirements. [Ref. 67:p 6-1] 

Three levels of functional decomposition are generally performed to 
provide enough description to suggest alternative architectures for evaluation. Figure 3 1 
depicts these three levels. The top level (level 0) functional flow diagram shows a 
general overview of the activities performed during the mission. The second level (level 
1) shows the functions that are done in each activity. The third level (level 2) breaks 
down in greater detail the actions that are performed for each function in level 1. After 
a concept has been chosen, the functional decomposition will be broken down further to 
reflect a particular design. [Ref. 65:p 21] 

(3) Definition of System Alternative Architectures. An architecture is 
a statement of what is required to accomplish the mission. The statement includes the 
hardware, software, personnel, and operational items to be used. "It is the allocation of 
system functions among defined system elements." [Ref. 65:p 23] 

Since there are a number of ways to accomplish the same task using 
different technologies, procedures, or equipment, a study of several different methods 
must be accomplished to determine the optimal solution. This study must measure each 
individual system, on its own merits, in the accomplishment of the requirements. 
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Figure 31: Functional Decomposition [Source: Ref. 67] 
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Normally this would be accomplished through a value system of some kind. 
[Ref. 65:p 24] 

(4) Concept Evaluation and Selection. There are three steps to concept 
evaluation and selection. The first is to synthesize and refine the alternative architectures 
through a series of trade studies. The second step is concept selection. Based on the 
results of the trade studies and the weighted decision criteria described in the 
requirements analysis, the most promising system or concept is selected for further 
development. The results from the trade studies and the utility functions consisting of the 
decision criteria should have sensitivity analysis conducted for each system or concept. 
Small changes in performance, especially when the final scores are close, may change the 
optimal solution. A review of the scores will usually reveal a few key decision criteria 
that drive concept selection. [Ref. 65:p 30] 

The final step is concept definition. Concept definition takes the 
selected concept and formally defines its performance, physical configuration, and critical 
technologies. Performance parameters, error budgets, hardware and software 
specification, and human and machine interfaces are some examples of the areas that 
contribute to the system’s composition. Human factors engineering must play a vital role 
to ensure the system can be operated effectively, especially during periods of high stress. 
Survivability, maintainability, and availability criteria are delineated at this point. The 
final part of concept definition is a systems engineering management schedule with 
milestone decision points. [Ref. 65:p 30-35] 
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(5) Concept of Operations The Concept of Operations is written by the 
operational using command. It consists of a time sequenced narrative of system 
operations, system employment and deployment, and system readiness. [Ref. 65:p 35-36] 

E. A SYSTEM VIEW OF THE MARINE CORPS 

The Marine Corps is a highly complex organization; a "Band of Brothers" bound 
by tradition, esprit de corps, honor, loyalty, and patriotism. A system view of the Marine 
Corps can not provide a complete portrayal of the intricacies of America's warrior elite. 
It is useful and necessary for the purpose of this assessment, however, to reduce the 
complexities of combat development to a manageable, simple representation. There are 
several ways to represent combat development in varying levels of detail. The alternative 
chosen in this assessment is to view the entire Marine Corps as an enormous "system" 
designed to develop combat power and efficiently translate that power when necessary 
into combat force effectiveness. The system is composed of Marines and their 
organizations, weapons and equipment, and procedures and standards. 

Headquarters Marine Corps, the Marine Corps Combat Development Command, and 
the Marine Corps Research, Development, and Acquisition Command together, essentially 
serve as the systems engineering team for the Marine Corps, They manage the total 
system development effort within the Marine Corps to achieve an effective balance of all 
system elements. That balance is optimal when the combat effectiveness of the Corps is 
maximized within given resource constraints. The organization and procedures used to 
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achieve that optimal balance are absolutely vital to the success and future of the Marine 
Corps. 

Essentially, MCCDC serves as the systems engineer for the Marine Corps. The 
Commanding General of MCCDC has been assigned the responsibility of ensuring that 
the Marine Corps functions smoothly as an effective, integrated system and can 
accomplish its assigned missions. 

In many respects, MCCDC carries out a systems engineering process in the 
development of concepts and requirements. 

In a very basic sense, MCRDAC serves as the systems engineering management 
team for the Marine Corps. The Commanding General of MCRDAC has been designated 
as the Program Executive Officer (PEO) for the Marine Corps. As such, he has the 
responsibility, authority, and accountability for all Marine Corps acquisition programs. 

Basically MCRDAC carries out a systems engineering management process in the 
development of systems that are components of the overall Marine Corps "system". 

F. THE IMPACT OF APPLYING SYSTEMS ENGINEERING TO COMBAT 
DEVELOPMENT 

Applying a more rigorous scientific methodology to combat development has both 
positive and negative aspects. 

1. Positive Aspects 

If systems engineering is properly applied to combat development, several 
potential benefits exist. The most important benefit could be a more effective Marine 
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Corps; a Marine Corps that is capable of achieving a greater level of combat effectiveness 
within the same resource constraints. This greater effectiveness would be the result of 
attempts at balancing all of the elements of the system to maximize overall combat 
effectiveness. The trends mentioned earlier could be mitigated or eliminated entirely. 

An effective systems engineering methodology would also promote the idea 
of examining other elements of the system as potential solutions to any identified 
deficiencies. In the MTACCS program, for example, software development is seen as a 
significant challenge. One hypothetical method of reducing the software complexity can 
be found in altering force structure or procedures. In this example then, the difficulty in 
implementing the equipment portion of the overall solution is lessened through the 
implementation of change in other elements of the system. 

2. Negative Aspects 

Negative aspects include the likelihood of a lengthier and more costly combat 
development process. Complex "integrated" recommendations would be far more difficult 
to generate, evaluate, and validate. Considerable resistance to changes in doctrine and 
structure is almost a certainty. In addition, "integrated" recommendations have the 
appearance of the "big system approach." While "big system approach" has no formal 
definition, it appears to consist of two aspects. The first is an emphasis on complete 
development of a fully functioning system in one big step. The second aspect involves 
simultaneous modifications to several elements of the system. The MIFASS program, for 
example, intended to implement significant modifications to doctrine, equipment, and 
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procedures all at the same time. The experience of the MIFASS system has brought great 
disfavor on "big system approaches" that affect many facets of the Marine Corps system. 

G. CONCLUSIONS 

1. Little Faith in the "Big System Approach" 

The failure of MIFASS has caused the Marine Corps to have little faith in the 
"big system approach." This is unfortunate because it appears that the chosen alternative 
is a tendency toward evolutionary development of only one element of the Marine Corps 
system at a time: change some equipment, for example, and keep all other system 
elements relatively static. The trend towards evolutionary development appears to be 
beneficial; whereas the reliance on basic solutions that address only equipment, for 
example does not. While basic solutions are less complex, they trade a great deal of 
effectiveness away to achieve that lower level of complexity. Regardless of the bad 
experience of MIFASS, there remains a need to implement change in a manner that 
integrates all of the elements of the system. 

2. The Need for Systems Engineering in the Marine Corps 

As described earlier, the Marine Corps’ "system" is composed of three basic 
elements; people and organizations, weapons and equipment, and procedures and 
standards. Ideally, these elements are optimally proportioned and structured. Manpower 
levels, types and quantities of equipment, operating procedures, and such, have been 
carefully chosen to maximize the overall effectiveness of the system within the resource 
constraints imposed. 
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Revolutionary advances in any one of the elements can dramatically improve 
system effectiveness, but the new proportion or structure may no longer be optimal. 
Modifications to doctrine, procedures, or force structure, for example, may better 
complement a major advance in weapons technology that the current doctrine, procedures, 
or force structure. If no complementary modifications are made, effectiveness may be 
less than the maximum possible within a given level of resources. This equates directly 
to wasted resources. In some cases, advances in one element may even be countered by 
out of date practices in another element. 

In recent years, revolutionary advances have occurred most often in the 
development of weapons and equipment. Users and developers alike are tempted to solve 
most deficiencies with new technology. New technology alone, however, focuses on only 
one element of a complex system. Equal attention must be given to all elements of the 
system to ensure optimal use of resources. 

Robert Everett also believed that new technology should not merely be used 
to support a static organizational structure. Addressing the role of technology in the 
organization, Everett wrote: 

The problem with the staff is not how to support the staff, but how to get rid of the 
staff.... [Ref. 40;p 24]. To take advantage of distributed we must learn how to 
distribute the staff function itself, how to separate the peacetime from the wartime, 
and how to use computers to support the commander directly rather than the 
commander’s staff.... Much work needs to be done on finding ways to replace all 
kinds of people with machines in carrying out functions. [Ref. 40: p 23] 

Clearly Everett promotes the simultaneous evolution and integration of staff 
(Marines and their organizations), procedures, and technology (weapons and equipment). 
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In managing the Marine Corps as an enormous system, the systems engineering team 
must employ a scientific approach in order to efficiently maximize combat effectiveness. 
The Marine Corps must evolve continuously using these scientific methods as tools to 
direct its own evolution. 

3. The Impact of Continuous Evolution 

Continually balancing the elements of the system implies a continual 
reorganization. Frequent reorganization, however, is viewed by most Marines as more 
of a malady itself than as a cure for effectiveness shortfalls. When the "spectre" of 
reorganization raises its ugly head, few embrace it with enthusiasm. It is true that 
reorganization and changes in doctrine can disrupt the continuity within a command and 
degrade performance, at least initially. Changes such as these are frequently cited reasons 
for a lack of cohesion within a unit. 

Marines, like everyone else, are creatures of habit; more comfortable with 

routine than chaos. Adaptability and flexibility, however, are vital to the success of the 

Corps. In the midst of revolutionary advances in weapons, computers, and 

communications, the remaining elements of the system cannot remain static. They must 

keep pace. In reflecting on the relationship of technology to command in his book 

Command in War. Martin Van Creveld wrote; 

... The most important conclusion of this study may be that there does not exist, nor 
has there existed, a technological determinism that governs the method to be 
selected for coping with uncertainty. At various periods in history, and in the face 
of any one set of requirements arising from the art of war as exercised in those 
periods, different military organizations, though making use of the same general 
communications and data processing capability, have approached the problem from 
radically different angles with radically different results. There was nothing in the 
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nature of any single technology, whether based on the signum or on the telephone, 
the messenger or the computer, to dictate which of two solutions should be adopted. 

Far from determining the essence of command, then, communications and 
information processing technology merely constitutes one part of the general 
environment in which command operates. To allow that part to dictate the structure 
and functioning of command systems, as is sometimes done, is not merely to 
become the slave of technology but also to lose sight of what command is all about. 
Furthermore, since any technology is by definition subject to limitations, historical 
advances in command have often resulted less from any technological superiority 
that one side had over the other than from the ability to recognize those limitations 
and to discover ways - improvements in training, doctrine, and organization - of 
going around them. Instead of confining one’s actions to what available technology 
can do, the point of the exercise is precisely to understand what it cannot do and 
then proceed to do it nevertheless. [Ref. 40:p 274-275] 

4. The Point of This Chapter 

The principle theme of this chapter is this: while technology is capable of 
marvelous achievements, it continues to be only a part of a larger system. To make 
optimal use of technology does not necessarily maximize the effectiveness of the system 
as a whole. Each element, the personnel, procedures, and technology, of the system must 
be properly balanced to achieve that maximum effectiveness. In his book Technology and 
War. Martin Van Creveld wrote: 

... let us turn to the first paragraph on the first page in the first chapter of 
Clausewitz’s On War . Here, armed conflict is defined as an act of violence where 
each side is out to destroy the other. This makes it into the province of hardship 
and of suffering, of stress and fear, and pain and death. ... war is, therefore, 
primarily an affair of the heart. It is dominated by such irrational factors as 
resolution and courage, honor and duty and loyalty and sacrifice of self. When 
everything is said and done, none of these have anything to do with technology... 
so it was at a time when war was limited to face to face clashes between hide-clad, 
club-armed cavemen 50,000 years ago; so it will be when laser firing flying saucers 
permit it to be fought over interplanetary distances 100, or 500, or 1,000 years 
hence. [Ref. 68;p 313-314] 
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Adherence to a systems engineering process in combat development has the 
potential of mitigating some of the current trends and restoring the oft neglected elements 
of the system to their proper levels of emphasis. The trend toward an equipment 
orientation, for example, can be lessened if modifications to doctrine, force structure, 
procedures, and such, are more readily accepted as candidate solutions. 
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VU. MTACCS INTEROPERABILITY ASSESSMENT 



A. INTRODUCTION 

1. Objective 

The purpose of this chapter is to describe the problems encountered in 
achieving interoperability in past programs and assess the direction MTACCS is taking 
towards interoperability. 

2. Methodology 

From the very beginning, the developers of MTACCS have encountered great 
difficulty in their efforts to obtain interoperability among the MTACCS subsystems. This 
chapter begins with a review of the interoperability problems of the past and then follows 
with a description of the current efforts to enhance interoperability. It then concludes 
with an assessment of those efforts. 

3. A History of Interoperability Problems 

a. Historical Reasons for Interoperability Problems 

(1) Management Redundancy. Historically, the Department of Defense 
has tasked numerous agencies and organizations, as shown in Figure 32, with the 
development of interoperability standards. This has led in some cases to ambiguities in 
responsibility and authority for standards. There is no "czar" that could manage 
interoperability. There is a forum, the Military Communications-Electronics Board 
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Figure 32; Organizations involved in Interoperability [Source: Ref. 69] 

(MCEB), at which many of the key organizations meet. However, this board is not 
equipped to resolve interoperability issues in a timely fashion. The Joint Tactical 
Agency (JTC^A) was established to enhance interoperability at the theater/tactical level. 
The JTC^A, however, mat not be an effort of sufficient strength. Dr. Stuart Starr of the 
MITRE Corporation has written: 

(JTC^A) has limited influence, is under-resourced, and tends to be reactive rather 
than proactive... The key role in interoperability management devolves to the 
Service Program Executive Officers (PEO’s) and the Program Managers (PM). 
[Ref. 69:p 5-6] 
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In a few large scale programs^^, such as NIS, WIS, and TRl-TAC, 
attempts were made to consolidate authority and centralize development in an effort to 
coordinate interoperability. Although the performance of these organizations varied, there 
were several areas of relative consistency. In general, the organizations were too slow, 
too expensive, and resulted in little .success. [Ref. 71 :p 8] 

Since there is no central organization to establish DOD 
interoperability standards that are directive in nature, the responsibility for interoperability 
falls on the program manager. However, the program manager tends to be narrowly 
focused and the top priorities for many programs have been performance, schedule, and 
cost. Little effort has been expended to design interoperability into a program at its 
inception. Insufficient effort has been made to coordinate cross program adjustments 
when configuration changes were made. Proper emphasis has not been given to 
interoperability. [Ref. 69: p 8] 

(2) Architectural. systems are characterized by many interfaces that 
are complex, frequently changing, difficult to predict, and occupy many levels. A broad 
architectural vision must be established early to achieve and maintain interoperability. 
This vision must state clearly the relationship between systems. In the past there has been 



” The NATO Identification System (NIS) is developing the next generation query 
and response system to support NATO’s need for interoperable target identification 
capability. The World Wide Military Command and Control System (WWMCCS) 
Information System (WIS) was to modernize key facets of WWMCCS. TRI-TAC was 
chartered to develop a family of interoperable communications systems for the military. 
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no vision and architectures, if developed, were generally not continually adhered to. 
[Ref. 69:p 6] 

MIFASS, for example, had a very general vision and did not adhere 
to the stated architecture. When changes to the architecture were made, there was little 
coordination among the other MTACCS subsystems. 

(3) Proliferation of Standards. In order to be interoperable, the system 
must be configured to a single set of compatible standards. Currently, there are several 
agencies and directives developing and setting standards. This makes it difficult to 
determine the proper set of standards and building to "a" standard does not necessarily 
guarantee interoperability. [Ref 71;p 8] 

(4) The Expense of Backward Compatibility with Fielded Systems. 
Backward Compatibility entails enabling the system to be interoperable with older, fielded 
systems. Interoperability can be achieved through any suitable method, and need not be 
restricted to technological changes. These older systems usually utilize outdated 
technology, behind that being fielded in the new system. The Department of Defense has 
already invested an immense amount of money in C? system development and fielded a 
number of systems. Achieving backward compatibility can be extremely difficult and 
expensive. In addition, there are many unique systems within the different services. 
Because of their unique nature, these systems tend to be limited in their capability to 
interoperate with other systems. [Ref. 71 :p 8] 
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(5) Lack of Standard Testing Policy. Another common source of 
interoperability problems, is the manner in which systems are tested. As depicted in 
Figure 33, each service maintains testing agencies of its own. Additionally, many civilian 
testing and verification agencies and contractors are also used. There does not seem to 
be a central manager or overseer who can direct testing efforts in a singular direction nor 
is there a central repository of interoperability standards and information to serve as a 
baseline for testing. [Ref. 69;p 8] 
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b. Examples of Prior Interoperability Problems 

It has been noted previously that MTACCS was originally conceived as 
a "conceptual association" of systems. That definition, combined with weak configuration 
management, bred interoperability problems of immense proportions. The problem was 
particularly acute in the MIFASS program. By 1987, the Institute for Defense Analyses 
declared that "MIFASS would have little commonality with any other MTACCS system." 
[Ref. I2:p E-20] The development of protocols for the Unit Level Message Switch^"* 
(ULMS), for example, was neither coordinated with MIFASS nor with the other systems 
it was to support. MIFASS was developed with different message protocols and was 
incompatible with the ULMS. MIFASS was also incompatible with both the Position 
Location Reporting System (PLRS) and the Digital Communications Terminal (DCT). 
Work around solutions were required in order to provide common modes of operation. 
[Ref. 43:p 31] 



B. INTEROPERABILITY 

1. Definition of Interoperability 

As defined in JCS Pub 1-02, interoperability is; 

... the capability of systems, units, or forces to provide services to, and accept 
services from other systems, units, or forces, and to use the services so exchanged 
to enable them to operate effectively together. It is achieved among 
communications-electronics equipment when information or services can be 
exchanged directly and satisfactorily between equipment and/or users. 
[Ref. 70:p 190] 



The primary switching device for message transmission between command and 
control centers. 
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In simpler terms, interoperability is the ability to exchange data in a prescribed 
manner and to use extracted information from that data to operate together effectively 
[Ref. 71:p 3]. The information that is passed must be understandable to the 
receiver. 

Interoperability can be achieved through manual or automated methods. It can 
be designed into a system from inception or added as an applique after the system is 
fielded. Designed-in, automated interoperability requires that emphasis be placed in the 
four basic elements of interoperability. 

2. Elements of Interoperability 

There are four basic elements in achieving automated interoperability. 



1. Technical Interface Standards. These involve the "electrical engineering" aspects 
of the problem. This includes the interfaces among the data systems, modems, 
and receivers/transmitters as well as the waveforms and modulation designs. 

2. Message Standards. These are the data elements, data items, and individual 
message formats in which data is to be transmitted between operators. 

3. Operating Procedures. These refer to the procedures to be followed by data 
system operators in the establishment of data links and exchange of tactical data. 
These procedures should not be confused with the broader set of operational 
procedures that guide tactical actions. 

4. Database and Applications Program Standards. These define variable formats that 
represent information that is stored and processed in the system. [Ref. 69; p 2] 



As depicted in Figure 34, the four elements must be negotiated between 
programs. In addition to the four elements listed above, thoroughly tested configurations. 
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well trained operators, and configuration control (or management) of interfaces, are 
required to achieve interoperability. [Ref. 71;p 4] 

3. Methods of Interoperability 

The level of interoperability sought should be derived from careful assessment of 
the potential benefits and liabilities based on a broad and deep understanding of 
mission needs and program constraints. [Ref 69;p 5] 

Figure 35 depicts four of the five basic methods of interoperability. These 
methods describe ways to achieve a level of automated or manual interoperability. Any 
one of these methods can be the "best" solution for the situation, depending on the needs, 
goals, and resources available. 

The "swivel chair" and liaison team methods are quick, flexible, and initially, 
relatively inexpensive. These are generally best in temporary simations when 
organizations who normally do not work together are forced to interoperate during a 
conflict or exercise. Common modes and gateways are more "after the fact" 
interoperability fixes. These methods are generally applied to systems that are well along 
in their development or are actually fielded. Same system interoperability is 
accomplished in the design and development of a system. They are designed with the 
elements of interoperability being compatible. It is important to keep in mind that 1 00% 
interoperability with everyone is neither achievable nor necessary. The disparity in 
methods, systems, and political preference is a challenging obstacle to overcome when 
determining the appropriate level of interoperability. 
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Figure 35: Methods of Interoperability [Source: Ref. 69] 



a. "Swivel Chair" Interoperability 

The "swivel chair" is nothing more than a human translator between two 
incompatible systems. Figure 35 shows a person receiving information on one system and 
sending it out on another [Ref. 71: 5]. This method is, as one can imagine, quite slow 
and prone to errors. However, it is inherently the most flexible. The individual only 
needs to know how to read information from one system and input the information into 
another system. The need for "swivel chair" interoperability can occur due to 
incompatibility in any one of the elements of interoperability. The "swivel chair" method 
puts a heavy burden on training, and personnel assets, and compounds configuration 
management problems. The "swivel chair" method was used in Operation Urgent Fury 
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and Golden Pheasant due to the incompatibility of the cryptographic devices to 
interoperate with all of the others. [Ref. 69:p 7] 

b. Liaison Teams 

Interoperability can be achieved through the use of liaison teams. 
Although not depicted in Figure 35, liaison teams are very similar in operation to the 
"swivel chair". Each system uses a human translator to put data into the proper format. 
The advantage of liaison teams is that there is someone to help interpret the data from the 
sending organization. There are many instances in which organizations must be able to 
exchange information rapidly and with great accuracy while possessing separate, 
independent systems that are not interoperable. This occurs when two forces must 
temporarily work together to achieve a common goal, such as in Operation Desert Storm. 
The Allied coalition in that operation was comprised of many countries, several of which 
had never conducted combined operations with many of the other forces present. Liaison 
teams were used to overcome many interoperability problems. Under these 
circumstances, liaison teams and their equipment are exchanged between organizations 
or forces, to allow the exchange of intelligible information, and to achieve at least a 
limited amount of interoperability. This allows each organization to coordinate with one 
of their "own" and have direct interface with the command element of the original 
organization. 

The liaison team can greatly assist in the understanding of the capabilities 
and limitations of his forces. Generally, the richness of information provided by a liaison 
team far exceeds that of automated methods. Forces that have never worked together 
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before or were not intended to work together, generally require this high level of richness 
of information. 

c. Use of Common Modes 

Figure 35 shows two different systems interoperating. Even though the 
systems are different, they have achieved partial automated interoperability through 
agreement in the four necessary elements described earlier. Generally, this is "partial" 
interoperability with each system having some common modes with the other system. In 
this approach, it is common to have only a very austere interoperability capability. Both 
systems use compatible communications interface standards, message standards, operating 
procedures, and database and applications standards. This method requires increased 
testing to ensure interoperability. The training and configuration problems can also 
increase due to dissimilarities in the physical hardware and software. [Ref. 71:p 5] 

d. Use of a Gateway 

Two dissimilar systems can be made interoperational through the use of 
a gateway. This time there is an electronic translator that uses hardware and software to 
translate one system’s information into a format that is understandable to the other. As 
with the "swivel chair" method, neither system needs to have all the elements in common 
with the other system. [Ref. 71:p 5] 

Although faster and more accurate than the swivel chair, there are 
limitations to how much a gateway can do. Only certain standards can be translated, for 
example. From a training standpoint, the gateway would be transparent to the user, but 
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the system manager/maintainer would need increased training to handle the operation of 
the gateway. Configuration management may be easier depending on the capability of 
the gateway. The more capable the gateway and the more protocols and standards it call 
handle, the easier the configuration management due to the increased flexibility. 
[Ref. 72] 

e. Use of the Same System 

As shown in Figure 35, using the same system is a reliable method of 
achieving automated interoperability. Each system would have the same interface, 
message, operating, and data standards as the rest of the systems. The training would be 
the same for each user, and the configuration management would entail configuring only 
one system. [Ref. 71 ;p 5] 

4. Steps to Achieving Interoperability 

Figure 36 shows a pictorial representation of the basic steps to achieving 
automated interoperability. The steps put into action the elements of interoperability and 
demonstrate a sequence for minimizing problems. The feedback loops highlight the 
extensive amount of time and coordination that must take place. The steps include: 

1. Establishing System Requirements. These requirements must be based on a 
mission perspective. These should be recorded in a Technical Interface Concepts 
Document. 

2. Develop and Specify Standards. These include message, interface, and 
database/applications programs. These should be captured in a Technical Interface 
Design Plan. 
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Figure 36: Steps to Interoperability [Source: Ref. 69] 

3. Specification of Operating Procedures. These include the interface operating 
procedures, the establishment of data links, and methods of exchanging data. 

4. Development of Interfaces. These are the individual system interfaces. 

5. Test of Interface. This includes the development and implementation of an 
Interface Test Plan. 

6. Training. This is the operational training of the operators to ensure their 
proficiency in establishing links and exchange of data. 

7. Fielding. 

8. Control of Configuration. This is managing and controlling the interfaces when 
the system becomes operational to ensure continued interoperability. [Ref. 69] 
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5. Benefits and Liabilities of Interoperability 

Interoperability yields many benefits, but not without a price. A highly 
interoperable system suffers from liabilities as well. Both are discussed here. 

a. Benefits 

(1) Automated Interoperability. Many of the benefits are obvious. In 
particular, the minimization of errors in transmission and the increased speed of 
information processing and transmission are important benefits. There will be reductions 
in the amount of people necessary to perform "translation" services. Interoperable 
systems perform without the need for data to be massaged into new formats. 
Maintenance costs are reduced due to a limited amount of diversity in equipment. The 
equipment is all physically similar and/or operates in common modes. This reduces the 
amount of personnel, training, and spare parts required to maintain the system. [Ref. 69] 

(2) Appropriate Methods of Interoperability. As noted above, there are 
some obvious benefits to automated interoperability. There are, as well, some not so 
obvious benefits of interoperability that transcend all interoperability methods. In general, 
interoperability leads to each unit having a relatively similar perception of the battle and 
the surrounding environment. This can lead to a stronger resistance to enemy actions. 
Friendly forces reap a synergistic benefit from working together without wasting effort 
or resources and can more easily reconfigure around a destroyed node or command center. 
[Ref. 69] 
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b. Liabilities 



(1) Standardization Makes Things Easier for the Enemy. In his book. 
Technology and War , Martin Van Creveld took particular care to point out the liability 
of standardization: 

However desirable or necessary (standardization) may be from the point of view of 
efficiency, in war its result is to make things easy for the enemy. The amount of 
uncertainty with which he is confronted is diminished. He is put in a position 
where resources and attention can be focused on countering a single threat instead 
of many different ones. Finally, he is spared the dilemma of having to do two 
contradictory things at once; which probably represents the most important single 
way of using technology (or anything else) in order to obtain victory in war. 
[Ref. 68:p 319] 



There are new vulnerabilities with automated, interoperable systems. 
In the past, a software virus was isolated to the few systems it could effect. Now, with 
automated, highly interoperable systems, viruses are compatible with all the systems and 
can create crippling disruptions in vast networks. [Ref. 71:p 6] 

(2) Integration can Diminish the Capability of the System. Despite the 
fact that some systems can achieve "state of the art" levels of speed and efficiency, they 
must often conform to interoperability standards which direct a less efficient method of 
operation [Ref, 71]. These operability standards usually derive from older, outdated 
systems that, with today’s technological pace, are nearing obsolescence. Although this 
practice may be more cost effective in the short term, it is only marginally effective in 
the long run. [Ref. 39] 

When new systems are required to run in a mode that emulates outdated equipment, 
increased performance benefits of the newer system are sacrificed. These benefits 
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that are sacrificed are often the justifications for procuring the system in the first 
place. [Ref. 39:p 48] 

A current example of this liability involves the Single Channel 
Ground Air Radio System (SINCGARS). SINCGARS is a single channel, frequency 
hopping VHP radio designed to be resistant to jamming. However, in order to operate 
with the older PRC-77 and VRC-12 VHP radios, it must often suspend its frequency 
hopping capability and operate on a single frequency. 

(3) Interoperability Costs More. Interoperability requires increased 
coordination. This requires more man hours which leads to higher costs. These man 
hours result from increased effort in configuration management and from the limitations 
placed on the size, weight, and power of the equipment to be built. Another cost in 
achieving interoperability is attaining backward compatibility. Backward Compatibility 
entails enabling the system to be interoperable with older, fielded systems. 
Interoperability can be achieved through any suitable method, and need not be restricted 
to technological changes. These older systems usually utilize outdated technology, behind 
that being fielded in the new system. It can become cost prohibitive to design the system 
in development to both comply with older operational standards and interfaces and 
achieve "state of the art" capability as well. This tends to restrict the full utilization of 
"state of the art" technology. [Ref. 71] 
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C. INTEROPERABILITY ASSESSMENT 



1. Findings of the Naval Research Advisory Committee 

The Naval Research Advisory Committee (NRAC) published a report shortly 
after the demise of MIFASS. The report examined the intra/interoperability capabilities 
of the Marine Corps. They found that many interoperability deficiencies existed, 
primarily due to a lack of strong, central coordination. This led to many configuration 
management problems with MTACCS and its associated subsystems. The tactical data 
interfaces were inadequately defined or satisfied. As stated earlier, this led to problems 
with basic interoperability between MIFASS and the message switch that was to handle 
MIFASS’ message traffic. The documentation was reactive instead of directive and was 
not internally consistent. Standards were not enforced uniformly and waivers were the 
rule instead of the exception. {Ref. 8,43] 

The committee also stated that the crucial performance standard of a C^ system was 
its level of interoperability [Ref. 43]. A system that can not interoperate, commands 
and controls very little and receives little outside information. The committee proposed 
recommendations for improvements in three areas. Those recommendations are outlined 
here; 

a. Systems Engineering 

The system baseline should be based on an open architecture with 
standard interfaces. This will allow developers and designers to "plug in" their projects 
and will force a set of standards. System engineers must concentrate on what is 
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achievable in the near term and incrementally enhance the system, aiming for maximum 
integration of tactical data systems, automated information systems, and tactical 
communications systems. [Ref. 43:p 4] 

b. Management 

A strong, centralized intra/interoperability configuration management 
authority should be established with unambiguous re.sponsibility for all tactical data and 
communications systems. Baseline documents should be transformed into authoritative 
guides. These documents should be regularly reviewed and updated to incorporate new 
technology and maintain internal consistency. [Ref. 43:p 5] 

Management continuity is a problem that can be solved through career 
planning and development for Marine Corps officers. This coupled with long term 
technical support for program managers should enhance configuration management and 
minimize the changes to requirements. [Ref 43:p 5] 

c. Implementing Strategy 

The Committee stated that near term efforts should concentrate on 
documentation updates, implementing FIREMAN^^, and planning for enhanced tactical 
communications. The implementation of FIREMAN should be treated as part of a larger 
C? systems, and not just a separate entity. It should be acquired through an evolutionary 
strategy using off-the-shelf equipment and software. Command and control data 
requirements should be re-evaluated for all phases of MAGTF operations. All critical 

FIREMAN has developed into the Tactical Combat Operations (TCO) system. 
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design constraints (such as data security/integrity and system robustness) must be defined. 
An overall architecture should be adopted which satisfies near term needs and supports 
future growth, [Ref. 43 :p 5] 

2. Current Marine Corps Efforts to Enhance Interoperability 

The timely, accurate, efficient, and secure flow of vital processed and tailored 
information is the key to removing the uncertainty associated with the chaos of war. 
[Ref. 73:p 81] ... technology alone is not the total solution. It is absolutely 
essential that standards be developed and adhered to by all members of the joint 
and combined community, so that our technologically advanced equipment can 
interoperate effectively to collect, process, and disseminate the flood of information 
that currently threatens to inundate the commander. [Ref. 73:p 83] 

The current efforts of the Marine Corps to enhance interoperability are 



threefold. 



a. Organizational efforts 

In an effort to highlight interoperability requirements. General Alfred M. 
Gray has reorganized the offices responsible for interoperability in the Marine Corps. In 
Signal magazine. General Gray wrote: 

The Headquarters, U.S, Marine Corps, has been reorganized to merge the 
Intelligence and Command, Control, Communications, and Computers (C^) divisions 
into the Command, Control, Communications, Computers, Intelligence, and 
Interoperability (C^I^) Department. This step has, for the first time, given formal 
cross-discipline visibility in the complementary fields of C* and intelligence. With 
the addition of the second 'T' for interoperability, that concern so critical to C^ 
systems has been elevated to the position of importance that it deserves. 
[Ref. 73 :p 82] 

This reorganization has consolidated the interoperability focus to facilitate 
the coordination and distribution of standards, yet has maintained the focus in three key 
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areas of systems development and acquisition. Currently, there are three organizations 
responsible for ensuring intra/interoperability: 

1. C''!^ Section at HQMC - Responsible for establishing policies and procedures for 
assuring intra/interoperability of all Marine Corps systems. 

2. MCCDC - Responsible for defining, validating, and publishing 
intra/interoperability requirements. 

3. MCRDAC - Responsible for cataloging, developing, and describing approved 
Marine Corps intra/interoperability standards for messages, data elements, and 
communications protocols. [Ref. 74] 

The relationships between the.se sections are depicted in Figure 37. The 
reorganization should aid in the establishment of a central configuration manager 
(MCRDAC), with clearly defined responsibilities as suggested by the Naval Research 
Advisory Committee. 

There are two interoperability organizations that are used to aid in 
establishing policy, requirements, and standards. The first is the Interoperability Planning 
Board (IPB), chaired by the Commanding General, C'*!^ HQMC. This board develops 
recommendations for interoperability policy; soliciting responses from the other 
organizations as shown in Figure 37. This board also controls the issuance of temporary 
waivers, weighing the impact of the waivers on other Marine Corps systems. The second 
key organization is the Interoperability Configuration Control Board (ICCB). This board 
is chaired by the Commanding General, MCRDAC and makes recommendations to 
MCCDC for changes to interoperability requirements and to MCRDAC for changes to 
interoperability standards. These recommendations are based on input from the Fleet 
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Figure 37: Intra/Interoperability Relationships [Source: Ref. 74] 
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Marine Force and the other interoperability organizations depicted in Figure 37. Through 
the use of these boards, the interoperability cross coordination problem between programs 
that plagued MIFASS should be avoided in MTACCS. [Ref. 74] 

b. Administrative efforts 

There are a number of documents that delineate interoperability guidance: 



1 . MCO 3093.1. This order establishes policies and management procedures within 
the Marine Corps to ensure that both Marine Corps intraoperability and 
joint/combined interoperability standards are implemented in Marine Corps tactical 
C“l^ systems. This order is published by the Assistant Chief of Staff for 
Command, Control, Communications, Computers, Intelligence, and 
Interoperability. [Ref. 74: p 1-3] 

2. Interoperability Management Plan (IMP). This plan is written to ensure the 
exchange of critical tactical information in Marine Corps combat operations 
through interoperability management. Its aim is to facilitate the implementation, 
verification, and testing of standards on developing tactical data systems, 
prescribing coordination between various configuration management bodies, and 
to ensure interoperability requirements are adequately planned for and properly 
funded. The plan is published by the Assistant Chief of Staff for Command, 
Control, Communications, Computers, Intelligence, and Interoperability. 
[Ref. 75:p 1-3] 

3. Marine Corps Interoperability Configuration Management Plan (MQCMPT This 
plan addresses current requirements for configuration management and 
interoperability requirements and for message, data, and protocol standards. This 
plan is published by the Assistant Chief of Staff for Command, Control, 
Communications, Computers, Intelligence, and Interoperability. [Ref. 75:p 1-5] 

4. MAGTF Interoperability Requirements Concept (MIRO. The purpose of this 
document is to assist in meeting interoperability objectives by identifying and 
documenting interoperability requirements that have been established in doctrine. 
Additionally, this document is to provide an interoperability requirements baseline 
for the development of standards contained in the Technical Interface Design Plan 
(TIDP), and to validate input into joint C^ architectures. This plan is published 
by the Commanding General, Marine Corps Combat Development Command, 
[Ref. 76: p 1-3] 
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5. Technical Interface Pesi 2 n Plan (TIDP). This document provides approved 
Marine Corps intraoperability standards including message, data element, and 
protocol standards. The TIDP provides information on each tactical data system’s 
or interconnecting equipment’s interface description by outlining approved 
message, data, and protocol specifications including those that temporarily deviate 
from the standard through approved waivers. This document is published by the 
Commanding General, Marine Corps Research, Development, and Acquisition 
Command. [Ref. 77:p 1-3] 

6. Interoperability Data Base System (IDBS). The IDBS maintains MIRC 
interoperability requirements and supports the interoperability program and 
configuration management of interoperability requirements and standards. 
[Ref. 74] 



The steps to interoperability specifically state that a Technical Interface 
Concept Document and a Technical Interface Design Plan be written to aid 
interoperability. As noted aboye, the Marine Corps complies with these 
recommendations. The steps also list a configuration management plan. The Marine 
Corps has written an Interoperability Management Plan and an Interoperability 
Configuration Management Plan. The updating and rewriting of Marine Corps 
Interoperability documents is a step toward fulfilling Nayal Research Adyisory Committee 
recommendations to redo the documentation. NRAC stated that the documents in 1987 
were reactive and not directive. An evaluation of the rewritten documents was not an 
objective of this thesis. However, the increased visibility of these documents 
demonstrates a general trend towards increased interoperability awareness. 

c. Technical efforts 

From a technical aspect, the Marine Corps is working towards increasing 
use of industry standards. This will allow common, tested interfaces, operating systems. 
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and hardware. In closely watching the development of other service systems, the 
Marine Corps is kept abreast of what it will take to maintain interoperability. 
[Ref. 34;p 4.3] 

3. Assessment of MTACCS Efforts to Enhance Interoperability 

a. Introduction 

This section discusses the current efforts, for which documentation was 
available, in MTACCS and how they measure up to recommendations that have been 
stated concerning the proper way to ensure interoperability. 

b. MTACCS Interoperability Elements 

(J) Technical Interface Standards. As stated in a report commissioned 
of the Pacific Northwe.st Laboratories, MTACCS will employ industry standards for 
communications and storage interfaces and will use NDI common buses for peripheral 
compatibility [Ref. 34;p 4.3]. Repeatedly stated throughout MTACCS documentation, is 
the concept of common hardware and common software [Ref. 2:p 1-5]. The common 
hardware and software must meet the standard interfaces set forth in the Technical 
Interface Design Plan (TIDP), or in order to maintain consistency, the standards must 
change to keep pace with technology. This will save in redesigning new standards and 
provide industry an opportunity to start designing and building using standards with which 
they are familiar. This will allow the employment of a wider array of Commercial-off- 
the-Shelf items and will greatly enhance interoperability due to the great proliferation of 
similar computers throughout the military around the world. The system is to be built 
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around an open architecture using a modular concept. This will facilitate the 
upgradability of the system, and should be readily attainable through the use of predefined 
hardware and software interfaces. 

(2) Message Standards. Message standards have been published in the 
Technical Interface Design Plan (TIDP) However, Pacific Northwest Laboratories has 
stated that these are incomplete for use across all MTACCS functional areas and cautions 
against progressing past FDS 1, until there has been a proper integration of applicable 
Marine Tactical System (MTS) messages [Ref. 34;p 4.33]. The use of the POSIX^® for 
system support software does allow for a limited variety of message formats 
[Ref. 34:p 4.9]. The program managers and prime contractors of MTACCS subsystems 
were interviewed concerning the impact MTACCS would have on their system. A large 
part of the discussion centered on the impact of connectivity, namely the message formats 
and operating systems. The visibility of this problem is one positive step in the correct 
direction. [Ref. 34:p 4.1] 

(3) Operating Procedures. At this point in time, specific operating 
procedures have not been defined. As stated later in this section, MTACCS is currently 
in step two, specification of interfaces and information, of the steps to interoperability. 
This step must be completed before step three, specification of operating procedures. 



36 



A standardized open system computer operating environment based on UNIX. 



(4) Database and Program Applications Standards. At this point in 
time, the Marine Corps has decided there would be common software and common 
applications programs. This lends itself to interoperability, at least within the Marine 
Corps, by the use of the same systems. The Marine Corps is currently investigating 
Database Management Systems (DBMS) and has not yet set a standard. [Ref. 34:p 4.20] 

c. MTACCS Level of Interoperability 

(1) Current. Currently, the Marine Corps has made great strides through 
Operation Desert Storm. Many communications problems have been, at least temporarily, 
ironed out through the use of borrowed or reconfigured equipment. The aviation element 
of the Marine Corps has been interoperable for many years, not in every system, but in 
the overall scheme. Useable information in the proper format is passed to other services 
and foreign militaries. In examining the levels of interoperability, the majority of the 
Marine Corps would fall in the "swivel chair" or liaison team category of interoperability. 
A Marine would physically transfer the information from one system to the other, be it 
a manual or automated system, or explain a situation and transfer information to another 
organization. As stated above, much of the aviation element of the Marine Corps 
interoperates in the common mode. Different systems with common methods of 
transferring data. 

(2) Anticipated. The intent in integrating MTACCS with fully 
developed and/or fielded systems is to only integrate them to the extent possible without 
causing major revisions to their elements [Ref. 32:p 17]. This infers that major systems 
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that are to be fielded will only make minor changes, initially to enhance interoperability. 
Long term interoperability standards will be developed, but compliance with those 
standards will be achieved in an evolutionary manner. There will be limited forced 
interoperability at first, and then through the evolutionary development of MTACCS and 
the product improvements of its subsystems, MTACCS will achieve a greater measure of 
interoperability in time. It is envisioned that a "swivel chair" interoperability will be 
attained with systems currently developed. Systems in development should be able to 
attain some common modes of operation. Gateways will be developed to increase 
interoperability until systems life cycles progress in that their interoperability is upgraded 
through product improvement. Through these product improvements, MTACCS will 
achieve, in an evolutionary manner, full integrated interoperability. Interoperability with 
other services would be achieved through common modes of operation and gateways. 
Pacific Northwest Laboratories has been examining the functioning of the Army ATCCS 
and CASS programs as a reference for MTACCS. [Ref. 34:p ii] 

d. MTACCS Steps to Interoperability 

Currently the MTACCS program appears to be in the second step of 
specifying the technical interfaces and the information to be exchanged [Ref, 34]. The 
first step was accomplished in the original MTACCS concept stated in the late 1960’s and 
redone in the revitalization of the late 1980’s. 
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e. Avoidance of Historical Problem Areas 



(1) Management. As stated in MCO 3093. 1C, only one agency has the 
responsibility for setting and maintaining standards, MCRDAC. The others, C''!^ and 
MCCDC, identify problems, requirements, and set policy. The directives more clearly 
delineate standards and responsibility, although they apparently could be better, they are 
a step in the correct direction [Ref. 34]. At MCRDAC, an office responsible for 
disciplining the development of systems in accordance with set standards was established 
to ensure configuration management [Ref. 34:p A.33]. The last historical problem is that 
of proper priority. Interoperability has been a key buzzword for many years and is 
enjoying a lot of popularity. It is difficult to assess if this is enough to make an impact. 

(2) Architectural. MTACCS is defined as having an open architecture. 
It is being built in software modules on common operating systems. Common types of 
hardware are being used on which to operate the system. [Ref. 34] This should ease 
configuration changes and upgrades to the system. This should also enhance 
interoperability through the use of modules. 

(3) Standards. A key guideline for MTACCS has been to establish 
standards early. An early definition of standards can prevent a profusion of incompatible 
"standards. Early MTACCS subsystems, such as MIFASS, developed unique interfaces 
in the absence of an enforced common standard. The result was the incompatibility of 
MIFASS with other MTACCS systems. Pacific Northwest Laboratories has reinforced 
the concept of early standard development throughout their study. [Ref. 34] As stated 
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before, the Marine Corps has rewritten a number of its intra/interoperability standards 
documents and continues to examine solutions for undefined standards. 

(4) Systems. Backward compatibility could be an extensive problem. 
Pacific Northwest Laboratories has examined the problems of interfacing with established 
systems [Ref. 34]. While backward compatibility can be achieved by an interoperability 
method, a technological solutions appear to be the method of choice. Technological 
problems are beyond the scope of this thesis. However, a high priority must be given to 
backward compatibility, or the older, incompatible systems must be eliminated. 

D. CONCLUSIONS 

History is filled with examples of vastly superior forces failing to prevail or 
suffering actual defeat at the hands of dramatically weaker forces that possessed 
more flexible, responsive and effective C^ ... our intention is to ensure that our C^ 
systems foster sound tactical decisions that will enable commanders to focus their 
tremendous combat power at the enemy’s center of gravity. [Ref. 73:p 83] 

MTACCS should not significantly change operationally, the way Marines fight. It 
will provide more processed and useable information to the commander and reduce his 
processing time. Neither tactics, strategy, nor procedures are scheduled to change. 
[Ref. 27] Interoperability will be achieved by establishing standards and complying with 
these standards in an evolutionary manner. As MTACCS evolves, the various subsystem 
will progress through several levels or methods of interoperability. A subsystem may 
utilize liaison teams at first, then progress to a common mode or gateway, and eventually 
achieve full integration. It is envisioned that as the system is used, more efficient and 
effective methods of operation will be discovered. As each service gains experience and 
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shares the knowledge gained, higher levels of interoperability will be achieved. As 
demonstrated in Operation Desert Storm, the U.S. Military will be fighting in a arena with 
not just the other services, or NATO allies, but with a significant portion of the world. 
A computer terminal with translation, electronic mapping, and message handling 
capability can gready enhance the power focused at the enemy’s critical mass and is 
much more efficient than a liaison team. While more efficient, automated systems are 
not necessarily more effective. In actuality, liaison teams can not be completely replaced 
by automated systems. Liaison teams provide a richness of information not found in 
automated systems. 
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vm. CONCLUSIONS 



A. SUMMARY 

1. Purpose of the Assessment 

The driving goal of this assessment is to develop an understanding of the 
strengths and the possible risks inherent in the new MTACCS concept. Additionally, 
recommendations are proposed that offer methods of mitigating the impact of identified 
risk factors. 

2. A Challenging Task 

A quarter of a century has passed since the inception of MTACCS. Tens of 
thousands of man years have been invested in its development. Assessment of a project 
of this scope is an enormous challenge. The authors have expended considerable effort 
simply in attempting to develop a thorough understanding of the many complex issues 
involved. 

3. Limitations of the Assessment 

The scope of this assessment is very broad. Emphasis on any one subject has 
been necessarily limited. Many of the guiding directives and planning documents are 
written only in draft or are not yet written at all. Additionally, the MTACCS program 
is dynamic and evolving. Some concept decisions are being made even as this assessment 
is being written. All of these factors place limitations on the credibility of the 
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assessment. Much of the information contained in the assessment, however, remains 



current. The conclusions are intended to be general and do not address a fine level of 
detail. A finer level of detail is beyond the scope of this effort due to the limitations that 
have been discussed. 

4. Methodology 

An assessment of a command and control system may examine many factors. 
Assessments typically examine program management procedures, cost-effectiveness, 
performance, etc. In the case of MTACCS, the failure of the key MTACCS subsystem, 
known as the Marine Integrated Fire and Air Support System (MIFASS), was viewed as 
a principle driver of the "revitalized" concept. A thorough investigation of the MIFASS 
program revealed several key ares of concern. Important among these were the basic 
feasibility of the project, cost-effectiveness, combat development practices, and 
interoperability. This assessment then attempts to determine the likelihood of the 
"revitalized" MTACCS experiencing problems in the same areas. 

This assessment began with an investigation of a key MTACCS subsystem. 
MIFASS had crippling acquisition and system engineering problems and the project was 
canceled in 1987 after almost twenty years in development Chapter II detailed the 
difficulties encountered during the MIFASS program and discussed the causes of the 
MIFASS failure. 

After the termination of MIFASS, the MTACCS program was re-evaluated and 
a "revitalized" concept was published. Chapter in described the MTACCS concept as it 
is currently envisioned. Many of the guiding directives and strategy documents that 
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define MTACCS, however, are still in draft. While the basic thrust of the new concept 
is stable, some changes in concept definition are occurring even as this thesis is being 
written. 

The implementation of MTACCS is an extreme challenge. At least several of 
the objectives of MTACCS fall into the "high risk" category and may not even be 
possible to achieve at any reasonable cost and expenditure of effort. The assessment in 
Chapter IV was an evaluation of the feasibility of the MTACCS goals. 

It is often tacitly accepted that the automation of a particular task has inherent 
benefits that always result in improved combat effectiveness. Chapter V addressed the 
potential cost-effectiveness of MTACCS. The cost of MTACCS was related to its ability 
to increase effectiveness to determine if spending funds on MTACCS is an optimal use 
of resources. 

In Chapter VI, the Marine Corps’ Combat Development practices were 
reviewed to determine the impact of combat development on MTACCS. 

Chapter VII provided an assessment of the interoperability efforts of MTACCS 
and the levels of interoperability expected to be achieved. 



198 



B. 



CONCLUSIONS 



1. MIFASS 

a. Key Problems 

There were four key problems within the MIFASS program: 

1. A lack of consensus concerning the doctrinal issue of centralization versus 
decentralization. 

2. Unstable requirements definition that failed to state requirements in mission terms. 

3. Underestimation of the complexity of the task. 

4. Adherence to the traditional approach of concentration on hardware first and then 
the software. 

The clumsy and inefficient management system was a hindrance to the 
program, but the only devastating problem was the lack of the foundation necessary to 
establish the program in the first place: sound initial requirements definition based on 
appropriate doctrine. 

b. The Impact of MIFASS on MTACCS 

In response to both the Goldwater-Nichols Reorganization Act of 1986, 
and the termination of MIFASS in 1987, the procurement business in the Marine Corps 
has been radically changed. The old matrix organization has been replaced with a 
dramatically different acquisition system. 

It is unlikely that future Marine Corps efforts will try the "big system 
approach" with simultaneous development of several elements of the Marine Corps in one 
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big step”. Wary of falling into that trap again, current Marine Corps philosophy 
embraces the ideas of modular, evolutionary acquisition using non-developmental items 
as much as possible. The "build a little, test a little, field a little" approach will be used 
to prevent another MIFASS from happening. Avoiding the "big system approach", 
however, may result in a reliance on simple, basic solutions that trade away efficiency 
and effectiveness for simplicity. 

Only one aspect of the "big system approach" need be avoided. The 
Marine Corps should not attempt to develop a major system such as MTACCS in one big 
step. An evolutionary development is the preferred method. The second aspect of the 
"big system approach", however, remains a legitimate requirement. Integrated solutions 
that address all elements of the Marine Corps system are necessary to maximize combat 
effectiveness within resource constraints. 

2. The New MTACCS Concept 
a. General 

The new MTACCS concept properly anticipates the need for an 
automated co mm and and control system to support MAGTF operations. Automation of 
command and control tasks has the potential of significantly increasing the combat 
effectiveness of Marine forces. 



^ The "big system approach"basically entails simultaneous development of 
elements such as doctrine, force structures, and equipment and an emphasis on achieving 
an acceptable system in one iteration. 
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b. Feasibility 

The MTACCS concept is feasible. The use of an Evolutionary 
Acquisition strategy markedly strengthens the program. In an evolutionary, incremental 
development, advances in technology can be more readily introduced as upgrades to the 
core system. There are several factors, however, that can undermine the basic feasibility 
of the project. These factors must be addressed and mitigated to ensure they do not 
inhibit development. 

(1 ) Use of Data Communications. The MTACCS program must ensure 
that informal communications and voice radio are not entirely supplanted by data 
communications. To rely too heavily on data transmissions violates the spirit of Marine 
Corps doctrine and runs the risk, as Van Creveld said, of "reducing command to trivia" 
[Ref. 41 :p 273]. 

(2) Centralization. A clear vision of the degree of centralization of 
command and control must be established early and maintained. In addition, it is vital 
that the degree of centralization be strongly supported across the entire Marine Corps. 
There must be consensus. Division on this highly critical issue can cripple the program. 

(3) Communications Capacity. The simultaneous development of both 
MTACCS and its supporting communications system is a hauntingly familiar scenario. 
The MIFASS system was also intended to operate with communications equipment that 
was being developed concurrently. The communications capacity was inadequate then 
and it appears that the capacity remains inadequate despite the fielding of new equipment. 
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(4) Multi-level Security. There is a need to allow users of differing 
security levels to be able to access the same system using the same database. Until this 
can be done with a high degree of confidence, our intelligence sources could quite 
possibly be in jeopardy. Our intelligence system could be unintentionally violated. 
Fortunately, there appears to be a strong interest displayed, by both industry and the 
services, in the development of multi-level security for both military and commercial 
applications. It appears that the Marine Corps need only follow those developments 
closely and evaluate candidate methods to determine the method most appropriate for 
Marine Corps needs. 

(5) Software development. The MTACCS development team has laid 
out a development plan that incorporates all of the current "best advice". Adherence to 
this advice will certainly promote success. The challenge remains significant, however. 
Furthermore, the decision to maintain current doctrine and force structure without 
modification eliminates potential sources of mitigation of software complexity. It is 
possible, for example, that changes to doctrine could reduce the software burden. 

c. Cost-Effectiveness 

Automation of command and control functions has the potential to 
significantly enhance the combat effectiveness of the Marine Corps. The proper level of 
automation, however, may not be "all you can get". The most cost effective level of 
automation may be that which restricts automation to the higher headquarters; regiments 
and above. The value of automation at the lower echelons (battalion and below) can be 
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relatively small. Generally, this is because the burden of additional equipment and 
training requirements can outweigh the increased performance gained through automation. 
Additionally, many tasks at lower levels do not lend themselves to automation. 
[Ref. 58:p 11] 

Based on the results of the TCO study, automation of command and 
control tasks at the battalion level and below may not be the most cost-effective method 
of increasing combat effectiveness. The implication of this study is clear. Cost-effective 
automation of C' tasks at battalion level and below requires lightweight, easy to use 
equipment that addresses only those tasks that require automation. 

d. Combat Development 

(J) Trends in the Development of Command and Control Systems. 
Currently, there appears to be four general trends in the development of C^ systems. The 
first is an emphasis on equipment or materiel solutions. MTACCS appears to follow this 
trend. The MTACCS Master Acquisition Plan states that current command and control 
tasks will be automated (new equipment) but no changes will be made to force structure, 
doctrine, etc. 

The second trend is a reliance on basic solutions that addresses only 
one element of a complex system. MTACCS, for example, addresses primarily materiel. 
Other elements of the Marine Corps "system" will not be modified. 
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'I'lie tliiul trend is the use of an "appli(|uc approach" for command 
and control systems, h'orce structure, doctrine, and procedures are defined first and the 
C’ sy.stcm is applied as an appli(|ue. Merc, too, M’l’ACCS ap|x:ars to follow the trend. 

'Fhc last trend is the increasing emphasis of standardization over 
opiimization. Merely coping with technology is consuming a majority of our efforts. 
Oinimizing appears to be a lesser concern. M I’ACCS may well be following this trend 
as well. Only small, incremental improvements to automation are exfx.*cted. Gradually, 
tbe.se incremental improvements will aebieve a desired level of automation. Tbe majority 
of emphasis, bowever. ap|H“ars to be in achie ving a working system rather than optimizing 
effectiveness. 

(2) LiifU' Faith in the "lii^ System Approach". As mentioned previously, 
tbe I'ailure of MIFASS has cau.sed the Marine Corjxs to have little faith in the "big system 
approach." This is unfortunate because it apjx^ai's that the cho.scn alternative is a tendency 
to develop only one element of the system at a time: change some equipment, for 
example, and keep all other .system elements relatively static. While this method is less 
ccnnplex, it trades a great deal of effectiveness away to achieve that lower level of 
complexity. Regardless of the bad experience of MIFASS, there remains a need to 
implement change in a manner that integrates all of the elements of the system. 

The reduction of complexity through the use of an evolutionary 
development .scheme is highly de.sirable. Attempting to further reduce complexity by 
addressing only equipment, for example, may be sacrificing too much effectivcne.ss for 
the sake of simplicity. Standardization is emphasized more than optimization. The 
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integrated development of all elements of the Marine Corps "system" in an evolutionary 
manner has the potential of promoting both optimization and standardization. 

(3) The Need for Systems Engineering in the Marine Corps. In recent 
years, revolutionary advances have occurred most often in the development of weapons 
and equipment. Users and developers alike are tempted to solve most deficiencies with 
new technology. The MTACCS program is following a similar approach. Basically, only 
equipment will be changed. Force structure and doctrine will remain unaltered. 

New technology alone, however, focuses on only one element of a 
complex system. While technology is capable of marvelous achievements, it continues 
to be only a part of a larger system. Equal attention must be given to all elements of the 
system to ensure optimal use of resources. Modifications to doctrine, procedures, or force 
structure, for example, may better complement a major advance in technology than the 
current doctrine or procedures. 

Adherence to a systems engineering process in combat development 
has the potential of mitigating the current trends and restoring the oft neglected elements 
of the system to their proper levels of emphasis. Through trade-off studies, for example, 
appropriate doctrine, level of personnel, and types of equipment can be carefully chosen 
to optimize effectiveness within resource constraints. 

e. Interoperability 

It is important to note that 100% automated interoperability is neither 
necessary nor desired. Some method of interoperability must be utilized but that need not 
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entail an automated capability. In the case of MTACCS, interoperability will be achieved 
by establishing standards and complying with those standards in an evolutionary manner. 
It is envisioned that as the system is used, more efficient and effective methods of 
operation will be discovered. As MTACCS evolves, the various subsystems will progress 
through several levels or methods of interoperability. A system may utilize liaison teams 
at first, then progress to a common mode or gateway, for example. Automated 
interoperability of all C^ systems in the long term is a principle goal of the MTACCS 
concept. Computer terminals with translation, electronic mapping, and message handling 
capability can greatly enhance the power focused at the enemy’s critical mass and are 
more efficient than liaison teams, for example. Liaison teams, however, will never be 
entirely supplanted by automated methods. Liaison teams provide a richness of 
information to the supported unit that is generally impossible to achieve through 
automation alone. 

C. RECOMMENDATIONS 

The conclusions that have been expressed in this chapter indicate that the 
development of MTACCS remains a significant chaUenge. Several risk factors have the 
potential of seriously impeding the progress of MTACCS. Mitigation of these risk factors 
is not an easy task. The following recommendations offer potential opportunities for 
lessening the developmental risk inherent in the MTACCS programs and increasing 
combat effectiveness. 
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1. Sufficient voice channels must be maintained in the MTACCS system to support 
the concept of "implicit communications" because we communicate in how we 
talk; in our inflection and our tone of voice. 

2. The developers of MTACCS recognize that the communications capacity of 
current and near term Marine Corps equipment will quite probably be exceeded 
by MTACCS. A determination of the anticipated communications capacity need 
is difficult without a firm understanding of the specific information exchange 
requirements of MTACCS which have yet to be developed. Regardless, the 
communications capacity requirement for MTACCS must be determined quickly 
to allow for timely development of a solution to the problem. 

3. Continued emphasis must be placed on establishing multi-level security if TCO 
is to interface with IAS and provide unit commanders with real time intelligence. 
Without a demonstrated secure, trusted system, there will be little user support for 
allowing classified information of a sensitive nature to be passed on MTACCS 
nets. 

4. The lack of faith in a "big system approach" should not be permitted to cause a 
complete departure from integrated solutions. Some effort should be made to 
permit the concurrent evolution of doctrine, force structure, and procedures as well 
as material. Instituting the FASC concept along with current MTACCS objective, 
for example, may offer still greater effectiveness. Evolutionary development 
would remain the method of choice. The solution being developed would 
certainly be more complex. A total reliance on basic solutions should be avoided. 
Attempts to break a complex problem down into basic, manageable pieces have, 
in the past, resulted in many of the pieces being solved independently. This can 
lead to disjoint solutions that do not maximize combat effectiveness within the 
imposed resource constraints. 
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APPENDIX A: GLOSSARY 



AAW 

ACAT 

ACE 

ACG 

ACMC 

ADM 

ADPE-FMF 

AE 

AEP 

AFATDS 

AIC 

AOA 

APO 

APS 

ARC 

ASP 

ASPO 

ATACC 

ATCCS 

ATDL-1 

ATO 

C^ 

C^ 

C'l 

C*l 

Cf 

CATF 

CBRS 

CECOM 

or 

CLF 

CMC 



Antiair Warfare 

Acquisition Category 

Aviation Combat Element 

Acquisition Coordinating Group 

Assistant Commandant of the Marine Corps 

Acquisition Decision Memorandum 

Automatic Data Processing Equipment - Fleet Marine Force 

Acquisition Executive 

Adaptability Evaluation Program 

Advanced Field Artillery Tactical Data System 

Automated Information Center 

Amphibious Operational Area 

Acquisition Project Officer 

Acquisition Program Sponsor 

Atlantic Research Corporation 

Acquisition Strategy Plan 

Acquisition Sponsor Project Officer 

Advanced Tactical Air Command Central 

Army Tactical Command and Control System 

Army Tactical Data Link-1 

Air Tasking Order 

Command and Control 

Command, Control, and Communications 

Command, Control, Communications, and Intelligence 

Command, Control, Communications, Computers, and Intelligence 

Command, Control, Communications, Computers, Intelligence, and 

Interoperability 

Commander Amphibious Task Force 

Concept Based Requirements System 

U.S. Army Communications-Electronics Command 

Counter Intelligence Team 

Commander Landing Force 

Commandant of the Marine Corps 
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CNA 


Center for Naval Analyses 


COC 


Combat Operations Center 


Comm 


Communications 


COTS 


Commercial-Off-The-Shelf 


CSI 


Command Systems Incorporated 


CSS 


Combat Service Support 


CSSCS 


Combat Service Support Control System 


DASC 


Direct Air Support Center 


DBMS 


Database Management System 


DC 


Development Coordinator 


DCS 


Defense Communications System 


DC/S 


Deputy Chief of Staff 


Dcr 


Digital Communications Terminal 


DirDevCtr 


Director of the Development Center 


DOD 


Department of Defense 


DPM 


Deputy Program Manager 


DPO 


Development Project Officer 


ECM 


Electronic Counter Measures 


EDM 


Engineering Development Model 


EW 


Electronic Warfare 


FASC 


Fire and Air Support Center 


FDC 


Fire Direction Center 


EDS 


Field Development System 


HREFLEX 


Marine Corps Flexible Fire Support System 


FIREMAN 


Marine Corps Fire and Maneuver System 


FMF 


Fleet Marine Force 


FSCC 


Fire Support Coordination Center 


GAO 


General Accounting Office 


GCE 


Ground Combat Element 


GOR 


General Operational Requirement 


GPS 


Global Positioning System 


HQMC 


Headquarters Marine Corps 


HR 


Helicopter Request 


lAC 


Intelligence Analysis Center 


IAS 


Intelligence Analysis System 


IDA 


Institute for Defense Analysis 


IDASC 


Improved Direct Air Support Center 


IFASC 


Improved Force Automated Services Center 
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IDBS 

IIP 

ILSP 

IMP 

IOC 

IP 

ISIS 

ITT 

JCS 

JSIPS 

JSP 

JTC^A 

LAAD 

LAAM 

LCAC 

LCCF 

LHD 

MACCS 

MAFATDS 

MAGIS 

MAGTF 

MAP 

MATCALS 

MCASS 

MCCDC 

MCEB 

MCICMP 

MIRC 

MCO 

MCOTEA 

MCDEC 

MCRDAC 

MCTSSA 

MEB 

MEF 

MEU 

MIFASS 

MILOGS 



Interoperability Database System 
Imagery Interpretation Facility 
Integrated Logistics Support Plan 
Interoperability Management Plan 
Initial Operating Capability 
Imaging Processor 

Integrated Signals Intelligence System 
Interrogation Translation Team 
Joint Chiefs of Staff 

Joint Service Imagery Processing System 

Joint Service Program 

Joint Tactical C^ Agency 

Low Altitude Area Defense 

Light Antiaircraft Missile Battalion 

Landing Craft Air Cushion 

Life Cycle Cost Forecast 

Amphibious Assault Ship 

Marine Air Command and Control System 

Multi-service Advanced Field Artillery Tactical Data System 

Marine Air-Ground Intelligence System 

Marine Air Ground Task Force 

Master Acquisition Plan 

Marine Air Traffic Control and Landing System 

MTACCS Common Application Support Software 

Marine Corps Combat Development Command 

Military Communications Electronics Board 

Marine Corps Interoperability Configuration Management Plan 

MAGTF Interoperability Requirements Concept 

Marine Corps Order 

Marine Corps Operational Test and Evaluation Activity 

Marine Corps Development and Education Command 

Marine Corps Research, Development, and Acquisition Command 

Marine Corps Tactical Systems Support Activity 

Marine Expeditionary Brigade 

Marine Expeditionary Force 

Marine Expeditionary Unit 

Marine Integrated Fire and Air Support System 

Marine Integrated Logistics System 
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MIPLOG 


Marine Integrated Personnel and Logistics 


MIPS 


Marine Integrated Personnel System 


MOE 


Measure of Effectiveness 


MOPE 


Measure of Force Effectiveness 


MOP 


Measure of Performance 


MTACCS 


Marine Tactical Command and Control System 


MTP 


Manpower Training Plan 


MTS 


Marine Tactical System 


NAVELEX 


Naval Electronic Systems Command 


NRAC 


Naval Research Advisory Committee 


NDI 


Non-Developmental-Item 


0MB 


Office of Manpower and Budget 


OSP 


Other Service Program 


OT 


Operational Test 


P^I 


Preplanned Product Improvement Plan 


PDA 


Principle Development Activity 


PEO 


Program Executive Officer 


PLI 


Position Location Information 


PLRS 


Position Location Reporting System 


PM 


Program Manager 


PNL 


Pacific Northwest Laboratories 


POM 


Program Objective Memorandum 


RD&S 


Research, Development, and Studies 


RDT&E 


Research, Development, Testing, and Evaluation 


Ret 


Retired 


RGS 


Remote Ground Sensor 


ROC 


Required Operational Capability 


RPV 


Remotely Piloted Vehicle 


SAE 


Service Acquisition Executive 


SBB 


Switched Backbone 


SCR 


Single Channel Radio 


SDI 


Strategic Defense Initiative 


SEMP 


Systems Engineering Master Plan 


SINCGARS 


Single Channel Ground and Air Radio System 


SPAWAR 


Space and Naval Warfare Systems Command 


SRI 


Surveillance, Reconnaissance, and Intelligence 


TACC 


Tactical Air Command Center 


TADC 


Tactical Air Direction Center 
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TADIL 

TAO 

TAOC 

TAOM 

TAR 

rCAC 

TCO 

TCRPES 

rnsE 

TIDE 

TRSS 

TWAES 

TWSEAS 

UCI’S 

ULCS 

ULMS 

ULTDS 

USA 

USAF 

USMC 

USN 



Tactical Digiuil Information Link 
Tactical Air Operations 
Tactical Air Operations Center 
Tactical Air Operations Module 
Tactical Air Request 
Technical Control and Analysis Center 
Tactical Combat Operations System 

Tactical Electronic Reconnaissance Processing and Evaluation 
System 

Tactical Exercise and Simulation System 

Technical Interface Design Plan 

Tactical Remote Sensor System 

Tactical Warfare Analysis and Evaluation System 

Tactical Warfare Simulation, Evaluation, and Analysis System 

Unit Commander's Personnel System 

Unit Level Circuit Switch 

Unit Level Message Switch 

Unit Level Tactical Data Switch 

United States Army 

United States Air Force 

United States Marine Corps 

United States Navy 
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